cvs commit: ports/x11/libX11 Makefile distinfo manpages
pkg-plist ports/x11/libX11/files patch-src_ImUtil.c
Alexander at Leidinger.net
Thu Jun 7 11:29:21 UTC 2007
Quoting Kris Kennaway <kris at obsecurity.org> (from Thu, 7 Jun 2007
> On Thu, Jun 07, 2007 at 10:22:29AM +0200, Alexander Leidinger wrote:
>> Quoting Mark Linimon <linimon at lonesome.com> (from Wed, 6 Jun 2007
>> 20:55:38 -0500):
>> >On Wed, Jun 06, 2007 at 09:44:50PM -0400, Kris Kennaway wrote:
>> >>The FreeBSD project does not have the resources (or desire) to effectively
>> >>do full-time incremental X.org release engineering because of X.org
>> >>changes being continuously pushed into ports.
>> Who decides what is going in and what not? What changes are allowed to
>> go in and which aren't (read: what's the definition of "important"
> "Fixes an application crash" or "Fixes a security vulnerability" would
> be good reasons. "Fixes some manpage typos" or "Adds a new cursor
> theme" or "Adds some linux-specific cruft" would not be :-) I don't
> want to have to be the guardian of this myself so I hope the x11@
> mailing list will self-regulate with a bit of guidance.
> Basically everyone needs to be aware that commits to x.org core ports
> (those in the dependency path of xorg-libraries, basically) need to
> come with a clear justification of why the update is required, so if
> you are prepared to defend yourself with solid arguments on that point
> then you probably have a reason to proceed.
>> >The last I checked, i386 package builds take ~5 days, amd64 take ~7 days,
>> >sparc64 take more than 3 weeks. If we push point releases any faster than
>> >these dates, we will never have current packages. I think this would be
>> >a serious mistake.
>> 4 weeks would be still too fast for changes to X11 ports, I assume.
> That kind of timescale should be manageable.
Time will tell... :)
>> >I've spent a lot of time looking at why packages are so far behind the
>> >ports and the deep dependency trees are the major part of the problem.
>> So switching to recording explicit dependencies only would give a
>> speed improvement in this case (why shall we rebuild an application
>> which depends on some gnome libs but doesn't make some X11 API calls
>> directly, the package will not change significantly)?
> Sometimes a port doesn't care when a dependency changes, sometimes it
> does - how do you tell those two cases apart with 100% accuracy? I
> don't think you can.
I think it's within the "what do we use as run-depends"-class, isn't
it? We don't get it right in some cases, but most of the time we get
it right. When we don't get it right it's a bug, and it is resolved
fast for VIPs (Very Important Ports) and is not that critical for
For the actual-package-depends target (not committed yet, I hope it is
under testing in an exp run, don't forget the pkg-tools patch and the
clean target patch as they helps much) I have a simple patch which
allows to switch to explicit dependencies (not tested yet) on runtime.
This would have to be tested in a tinderbox first (any volunteers
around?), as I expect some problems. After that an exp-run would be
BOFH excuse #77:
Typo in the code
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the cvs-all