Sjors Gielen <mailingl...@dazjorz.com> said:
>
> Op 22 jun 2010, om 16:41 heeft Max Horn het volgende geschreven:
>
>> Well, there is always good old "grep", which gives the list below of 245
>> .info files containing the string "libjpeg-shlibs" in my unstable tree. Some
>> of those may not be really dependencies, but most probably are (I didn't
>> bother to remove libjpeg and libjpeg8 themselves, too). In any case, this
>> means that replacing libjpeg by libjpeg8 is a "bit" more complicated than
>> you made it sound in your initial email ;-).
>>
>> That said, I nevertheless would appreciate this transition (likewise the
>> transition from libpng/libpng3 to libpng14; readline to readline5; gettext &
>> libgettext3 to libgettext8; etc. etc.). But all those packages would have to
>> be tested. Many are unmaintained. Many are for very old stuff. Maybe some
>> should just be removed, but I wouldn't do that lightly, nor would I
>> recommend just changing them and hoping for the best...
>
> However, there is a way to make a package obsolete[0] and iirc, it makes -m
> builds of those packages fail (or otherwise I think it should and I will
> patch it in fink). Then, the work is split across all maintainers to do the
> switch themselves, and this will hopefully result in all packages eventually
> switching to the newest versions. The packages that won't be switched, then,
> are both unmaintainer and unused, and will switch the moment they become used
> again.
>
> If I now propose that libjpeg, libpng, libpng3, gettext, libgettext3,
> libdjvulibre15 and imagemagick1 get a fink-obsolete-packages dependency, what
> do you all think?
No. Changed library package-name means (loosely speaking)
backward-incompatible changes to lib interface. That means one really
needs to actually test, and migration may not actually be possible in
some cases. That is, there may be real reasons to stay with
other-than-latest soname, or at least no urgent technical reason to
force rebuilding to upgrade. The technical obsolete mechanism doesn't
have a way to make those distinctions...it's only for truely drop-in
replacements, where the upgrade is *guaranteed* to work, and it
provides a pathway to upgrade/migrate. Changed binary interface may
not be upgradeable, and the upgrade pathway certainly isn't always
"just change dep name", so it may not be possible to have a clean
system if you tag these as obsolete. The wiki page about the obsolete
mechanism is very clear about *not* using it for this purpose.
If there are technical problems that are solved by changing
dependencies, that's a major find, and certainly worth getting fixed
in those packages. If there are whole swaths of the dependency tree
that are self-consistently using (or at least mixing with no harm)
some older version, there's no technical reason to even strongly urge
them to change, let alone force it. It creates un-necessary rebuilding
for users (when the changes are made) or noise ("obsolete" warnings)
until maintainer fixes it. Again, for no gain except "someone wants
one less package in the tree".
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
