-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 6, 2005, at 6:22 PM, Max Horn wrote:
To clarify this once more (Justin just left IRC when I talked to him about this right now, it seems I am touching the feelings of some people here):
The Depends field *always* implied both a install time and a compile time dependency. This has been so from day 1 of Fink's existence. It has always been documented like this. Many packages, including all of mine, rely on this. It has been so for years, at least during all the time I was actively involved with Fink.
Yes, but we tried to change it last year, and the same argument was used, that it would break packages.
Maybe this was silently changed during my absence. OK, but then this has not been documented anywhere; in fact our docs still explicitly state what I claim above, and our code still does it this way.
Some maintainers decided to use it this way, and it was encouraged on new maintainers, but never forced.
Hence the only possible conclusion is that changing the behavior of the Depends field is indeed a *major* change of the semantics of the .info field. You may argue that it's a logical change; you may argue that's it beneficial, etc. etc. etc. -- that's all OK and we can debate it. However, you can't debate away that it *is* a major change.
No, it's a major change to the way maintainers write the .info file, not the way fink works (mostly). As long as fink index can index the new info files without error, all that will be needed is a builddep on the new fink. If not, maybe it is time to move to .info2 and implement a InfoVersion field, where fink will skip any major version higher than it knows about, to avoid breaking like we had when we radically redefined the fields in fink.
From this in turn I draw the conclusion that such a major change of a core feature of Fink would have to be:Yes, a mass mailing to all maintainers warning of impending breakage and a new item.
1) extensively documented, so that all packagers notice it and can deal with it accordingly
2) it would IMO warrant a revision of the .info file format. After all, after this change, the format *is* changed in a major way, the question is just whether you want to explicitly mark the file as being changed this way, or if you want to hide it and pretend nothing changed, when in fact it did.
The format did not change, just the final meaning of one of the fields. Variants was a major format change.
3) If you don't like a file format version change, consider *not* making this change. consider alternatives, like adding a RuntimeDepends field. Yeah, it's not nice, yeah, I'd prefer a clean Depends field -- but we have to start working from what we have, not what we wish we have, I think.
Very ugly.
In the end it boils down what you like more: a "clean" design in which the Depends field does what you want, or a real life approach, which is not as clean as the theoretical clean design (a new file format, or a new ugly field), but which works, is backward compatible and minimizes breakage. If you can achieve the clean design w/o breakage, I'll always prefer it; if you write a new system, I'll use it; if I have to update a system which is used by tens (hundreds?) of thousand people, I'll think thrice before making a potentially bad move....
While we do have many users, let's not forget were are not even at version 0.5, let alone a 1.0 release (although i feel we could declare 1.0 once a few things are fixed/added). We are allowed to have minor breakage in the name of progress. If we don't make at least *some* sacrifices, we will end up like Microsoft, with the potential for some great products, but being dragged down to garbage, that's compatible with old versions. In this state, where people are using such beta software, re-downloading a tarball and manually doing a ./inject.pl (or apt-get upgrade) is actually very reasonable. It may not be as pretty as fink selfupdate, but we have never made any claims that that will always work, nor do we have any responsibility to it. The people using fink need to realize this, that we will do our best, but it always comes down to "You get what you pay for." We would do much testing while the code was in HEAD, of course, and many, if not all, packages would be fixed by the time the new fink was released. Any old local info files would need to be updated, but that is not really our concern.
- -chris zubrzycki - - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 ======================================================== "Of course, you realize this means war." - -B. Bunny
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin)
iEYEARECAAYFAkIG9msACgkQ+/mCMqKrwHC5yQCg5yreRDihlpryVT0h0iFdcH48 n5sAoNtvzn7Yym4+FTzmAtHKPgAVJvwE =5J+R -----END PGP SIGNATURE-----
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
