[ATrpms-devel] Re: libgal2 & ImageMagick updates => remove other packages

[Axel Thimm]

On Fri, Jun 11, 2004 at 01:35:04AM +0200, Axel Thimm wrote:
> On Thu, Jun 10, 2004 at 03:24:23PM -0500, Rex Dieter wrote:
> > Axel Thimm wrote:
> > >On Wed, Jun 09, 2004 at 08:04:00AM -0500, Rex Dieter wrote:
> > >>On Wed, 9 Jun 2004, Axel Thimm wrote:
> > >>>>>an upgrade wants to remove
> > >>>>>ImageMagick556 kavi2svcd multisync perl-Video-DVDRip subtitleripper 
> > >>>>>transcode
> > >>OK, new ImageMagick556 compat is on the way...
> > >Thanks!
> > >
> > >Could you also do the same with libgal2?
> > What depends on libgal2?
> 
> Of the above, multisync, which I freshly packaged against stock libs.
> 
> An option would be to start upgrading libgal2 in ATrpms to stay in
> sync with kde-redhat, but that will only create more overlaps and
> would desync the next time libgal2 is upgraded in kde-redhat. Another
> would be to rebuild multisync in kde-redhat, which results in the same
> set of problems. So a compatibility lib would be really nice.

Well, I went with option 1 to get the compatibility up and running
fast. But now ATrpms is killing evolution, unless one uses evolution
for kde-redhat :(

I decided to provide comaptibility libs myself a la Mandrake
style. E.g. both libgal2 1.99.10 and 1.99.11 shared libs will be able
to coexist, thuis allowing mixing packages depending on one or the
other.

The Mandrake style splits out shared libs in unique package names like
libgal2.0_5 or libgal2.0_6. The drawback is that these shared libs are
not taken out in upgrades even if they are not used. But the
advantages are that no comptaibility lib is required - the packages
themselves already provide the forward/backward compatibility lib.

I have already employed this scheme (exactly taken from Mandrake to
not create another standard ...) in the following packages: alsa-lib,
pwlib, openh323, rpm, xvidcore, openquicktime, a52dec, libdv and now
libgal2.

I will continue splitting off the shared libs that way to ensure
compatibility w/o any hassle later. Rex, would you consider using the
same scheme? :)

> Probably a policy in replacement of base packages should be to provide
> compatibility packages when appropriate to cater for other ISVs (so
> mostly for shared libs). Not that this is a policy ATrpms has been
> strictly following, to be honest, but perhaps this should become a
> habit. Who knows what else depends on the base libs, one can only
> monitor the distribution itself and maybe one or two other repos.
> 
> I know, compatibility libs are no fun. :(
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20040615/13020cdb/attachment.bin