RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc.

[Mike A. Harris]

On Fri, 6 Feb 2004, Nils Philippsen wrote:

>Having been nudged politely, I'll respond now (albeit a bit late).

Late is always better than never.  ;o)


>On Mon, 2004-02-02 at 06:09, Mike A. Harris wrote:
>
>> Proposed Solution:
>> 
>> After much thought, my own proposed solution, is to do the 
>> following:
>> 
>> - Create a number of new "virtual Provides:" in the XFree86 rpm
>>   spec file in the XFree86-libs and XFree86-devel packages 
>>   respectively.  Essentially there would be one new virtual 
>>   provide for each library, and perhaps for developmental 
>>   utilities necessary for X development also, which are presently 
>>   in XFree86-devel.
>
>Full ACK, this could be even extended into adjacent areas, e.g. Mesa
>libs which once were in their own package and now are in XFree86-libs-GL
>or whatever -- and who knows where they will be when having fd.o libs
>becomes en vogue? There might even be more packages where this could be
>applied to: e.g. GLUT <-> freeglut, ImageMagick <-> GraphicsMagick, ...
>whereever there are alternative libraries that can be used.

Agreed.  Mesa will be split out into it's own rpms once again in 
the future as well, but without the pains that that once entailed 
(at least I hope not <grin>).  freeglut needs an update to the 
buggy placeholder package in FC1 soon, and I plan on putting 
virtual provides for glut in there also, along with the proper 
compat libs, headers, etc.

Seems to me like a good idea for the other packages as well.


>Sorry for not having found any quirks in your proposal ;-).

No problem, so far there have been mostly ACK responses, and 
more are always good.  ;o)

Someone brought up a concern over having every single X library
in it's own src.rpm, and the dependancy domino effect that would 
result, perhaps being a bit of a PITA to bootstrap, and perhaps a 
problem for other packages even.  That problem on it's own is a 
different issue entirely from the virtual provides issue itself, 
so doesn't completely fit into the proposal I requested feedback 
on, however it was nonetheless another issue that needs to be 
taken into consideration when actually doing the new packaging.

I'm going to experiment privately with one src.rpm per lib, but I 
have a feeling it might make more sense to group all of the 
common standard X libraries that rarely if ever change into one 
single foo-xlibs-common.src.rpm to avoid the interdependancies, 
some of which are kindof ugly (Xau depends on Xlib, Xlib depends 
on Xau).  If this is done, then the only libs that would be 
separate are ones that either:

1) Are fairly new, and under active development, such as 
   everything Keith Packard works on.

2) Frequently change to fix bugs and other issues

3) Are a common source of new security headaches being discovered 
   which need to be updated.


None of this should really be a problem for anyone other than 
myself however, and perhaps releng.  It would more or less be a 
self-solving problem though if everyone uses the new virtual 
requires I suggested in the proposal, as the packages would pick 
up the right lib deps without caring which rpm they are actually 
present in.

I'll probably post another message about the granularity of
library modularization in the future when it's closer to 
something useable.

Thanks again for the feedback!


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat