-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Macks wrote:
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.
This is all assuming that having the revisions match between the patch and the info file are important enough to make the committer go through the extra work to keep them in sync. I don't think it is, since it's easy enough to get it by date if you really need to know how they're paired up. Usually comments will be enough to figure out which is the relevant one.
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).
I guess I'm confused what the problem being solved is...
The original reason to switch to <name>.info and <name>.patch was to make it easier to find the history. That it does. Now it seems that because it's possible to look up history, we're ending up with proposals making things even harder than they already were for the most common every-day uses, by having new things you have to remember to do every time you make a change...
I think it's overkill to have to remember to update a patch every time the info file is changed, or to pack/unpack shar archives to make a package...
- -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/
"Just try to imagine a world where e-mails are sent by your brain
before they are written, and are ready before they arrive by people
you have never even met in countries you have never even heard of!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/D0VyUu+jZtP2Zf4RAvJyAKCchxk8hdVvNgTHY+lMPkrz5Z4j0QCeNza9 2oee8/2dRsiIHoZztrx0Wlw= =MreY -----END PGP SIGNATURE-----
------------------------------------------------------- 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
