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.



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.



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.



From this in turn I draw the conclusion that such a major change of a core feature of Fink would have to be:
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.
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.



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....




Anyway, this is just my personal oppinion. I don't want to step on anybody's toes with it; and I realize that I have been out of the loop for a long time. Maybe things I am not aware of happened which render this mail moot; that's fine, and I hope somebody will suffer my ignorance and explain them to me (sorry, I simply must have missed the relevant mails on fink-devel, which is no surprise, as I only read it very casually these days).


Best wishes, and keep up the good work,

Max



-------------------------------------------------------
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
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to