Re: Re: Idea: embed patch in .info

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