[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> > One thing to think of: the graphics libraries seem awfully confusing (ie
> > there's so many of them). Maybe it's worth shoving the two libjpegs,
> > libungif, libpng, libtiff, and anything else I've left out, into one big
> > graphics RPM ? 
> > 
> Not into an RPM.  In a metapackage or provide a "load everything" feature.
> Putting them into the same RPM, implies loading all each time one
> component cchanges.  In addition they are not related.
The reason I liked the rpm idea, is that I don't like the conflicts 
between our graphics libraries and the old ones like libgr.. yet ours 
currently does not totally obsolete libgr so it's kind of a mess. 
Maintaining a replacement graphics rpm should take care of such problems 
- no more having to --force our package to go in over the obsolete pieces 
of the old, and in cases where keeping the old version is useful, the header 
conflict in the devel package can be resolved by keeping one set in an 
alternate subdirectory.

All this stuff could basically be dealt with individual rpms that stuff 
conflicting headers into a new subdirectory and metapackage scripts that
know which old stuff may be written over, except..
it doesn't leave the rpm database as clean, the old packages stop verifying
if we start writing over stuff. Yuck.

Even if the jpeg and tiff libraries aren't "related" by function, they have
already been related with some other stuff by inclusion into the standard
libgr, so how about we just distribute a replacement libgr that includes the
updated versions? The other graphics libraries can remain independendently
distributed, and a metapackage can handle installing all of them,
new libgr + all the others like giflib etc., as a set if desired.

                              S. Lockwood