The only reason I saw when browsing through the thread was a concern regarding matching a .info file with the correct .patch file for it. Please correct me if i missed any other reasons.
Now, let's see whether 1) this is actually a problem, and 2) if it is, how to tackle it.
Regarding 1)
If you get a fink .info/.patch pair from somebody, that person is pretty much expected to send you a matching pair. If you get latest CVS, you get a matching pair. If you get a CVS checkout of a specific data - you still get a matching pair, as long as developers follow the rule of submitting modifications to the .info and .patch at the same time. This is the only correct behavior for any developer anyway.
So - could somebody please tell me any scenario where this "problem" really is a problem? Except for cases were people manually modify the .patch file, of course.
Regarding 2)
Next, let's say there are really cases where its possible for an unwanted incorrect .info/.patch matchup. Tackling this by using a whole new format (be it ar, tar, gzip, shar, or anything else) seems like a big step to me. One of the core strengths of Fink is how easy it is to make packages for this. That's largely due to the fact that packages are simple text files. Diverting from this in any way IMHO degrades this strength of Fink, even if we provide "easy" commands to achieve it. So IMHO there should be really strong reasons to do this. I'll wait for answers to 1) before I give my final opinion on whether this feature is worth such a change, but right now it looks to me (again my personal opinion): nope, it doesn't.
The other "solution" which nobody mentioned yet (or maybe I missed it), is rather trivial: we go back to the old scheme of renaming the .info/.patch file for each version/revision. Personally I like that solution much better than any ".info/.patch" combination technique. So far I have yet to personally experience actual advantages of the new "%n.info" scheme (I am curious, folks: tell me your success stories, things you were able to do with the new system which you couldn't do in the past. I am talking about real experience, no theoretical scenarios, please :-)
That said, I am supporting whatever turns out to be the best for Fink. But I'd suggest carefully considering what we are doing, and why.
Cheers,
Max
------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
