Max Horn said: : : 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.
A quick look at unstable/utils finds 20 or so packages where the .patch and .info have different rev's as a result of the -dev essentials fix, validator fixes, checksum additions, Source changes, typos. So one would have to bump the (CVS) rev of a corresponding .patch whenever this happens. All-told, about a third of the files there have rev>1.1, meaning something has changed without bumping up %v-%r. Also is the case where some %v-%r use a patch and others don't (the OS X patches get rolled into the next %v, the maintainer learns some flag that makes hacking the source no-longer-necessary, etc.) If we want to keep CVS rev#s in sync, once a patch has existed for any %v-%r, it must exist for every future one. If a patch isn't required, a CVS committer must remember to look for one and commit a blank .patch in order to keep the CVS revisions in sync, and the trees get littered with blank files. And if a patch is required when upgrading a package, a CVS committer must check if there was one previously, otherwise he must force a CVS rev to correspond to the .info. : 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. I agree with the "think long and hard before changing formats". That's why the things I had proposed in previous messages were pretty much just stringing the current files together (cf. an actual archive format), and keeping it transparent and optional. A combination of CVS tagging the .patch with %n-%r and using Patch-MD5 (as people suggested recently) would solve both sync problems I think? An .info could never use a wrong .patch, and one doesn't have to worry about keeping CVS rev#s in sync. Okay, what if we tag .patch, and then change from having the .patch in the tree to being something that is downloaded during build? That way we get CVS history, don't have to go crazy keeping CVS rev#s in sync, and a given build process will always find the corresponding .patch? Would require a mightly reliable CVS server (but could run on a mirror if SF would enable such, or else seeding some other CVS server with the SF nightly tarball). : 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. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- 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
