Personally, I am very much biased against this whole idea. But let's
look at it rationally.
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
|
