cvs commit: ports/x11/libX11 Makefile distinfo manpages pkg-plist ports/x11/libX11/files patch-src_ImUtil.c

[Alexander Leidinger]

Quoting Kris Kennaway <kris at obsecurity.org> (from Thu, 7 Jun 2007  
05:16:05 -0400):

> 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"
>> here)?
>
> "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.

Ok, thanks.

>> >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  
"niche-ports".

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  
interesting.

Bye,
Alexander.

-- 
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