Am 07.02.2005 um 14:22 schrieb Peter O'Gorman:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Peter,
Daniel Macks wrote: | | That raises an interesting question: are we going to bump %r on each | package we change to this new SHLIB_DEPS form?
I am obviously missing something by skim reading this thread. Why are we
going to be adding SHLIBS_DEPS to a package which already has a "perfectly
good" list of dependencies? This can be done gradually, surely, by
maintainers updating their packages:
Yes, that's how I think it should be implemented. However, if we do it as e.g. Justing wants to, and change the meaning of the Depends field, then this update can not be performed gradually. That's more or less what I am complaining about, and what Martin Costabel explained very nicely in his mail, I think (thanks Martin).
"I have to update foo. Hey, just add a couple of builddepends from the
depends line, remove a whole bunch of -shlibs packages from the Depends line
and add {SHLIBS_DEPS} there. Update the version/revision and md5. Wow! Bob
really is my uncle!"
There should be no necessity to go through globally changing most of the
packages which exist (or worse doing it automatically in fink).
I fully agree. Which is why I don't like the idea of silently changing the meaning of the Depends field (or changing it loudly by mailing all maintainers either). So I think we either shouldn't do that at all, or if we do it, do it in a fashion that makes it possible to have "old" and "new" style packages co-exist, to allow for a smooth migration.
I certainly
don't want to have to bother doing that with mine. Until quite recently I
still had a package which built twice, once to get the package built and
again to get the -shlibs in a different .deb (pre Splitoff shared libs
policy), this package still built and worked fine with current fink.
We need to be able to let maintainers be as lazy as possible. I believe that
the SHLIBS_DEPS work will help in that goal, if it is implemented correctly.
Sure. I am not arguing against that field, for the record, just against the radical change of the semantics of a fundamental field...
Slightly off topic: People may rant about the MS backward compatibility as much as they want -- I for one think that it has many good points, too. And hey, Apple went that route, too (think of 68k->PPC, or OS9->OSX -- w/o the 68k emu, or Classic, I think Apple would be were commodore and Atari are now... :-). We hacker and coder often tend to forget that and are quick to throw away everything in favor for a new, better reason. Other people just want to use their computer and aren't so happy when they have to redo everything and gain (in their perception) virtually nothing for all the effort... :-/
Cheers,
Max
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
