Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski in <[EMAIL PROTECTED]>: : On Fri, 18 Jun 2004, Bas van Gompel wrote: : : > Op Tue, 15 Jun 2004 16:52:31 -0400 (EDT) schreef Igor Pechtchanski : > <pechtcha at see es dot and why you dot ee dee you>: : : Cute, very cute...
Ehh... Thanks, I think. [...package maintainers could take...adapt the CVS HEAD of the GBS...] : > I am not a package maintainer, so EMBI. : : I'm not familiar with the acronym. Excuse My Butting In. : What I meant by "package maintainers : take time to adapt the CVS head of the GBS" was that most packages now use : an older version of the GBS, and don't keep the CVS Id, so that makes it : very hard to determine the exact set of changes that everyone had to make. I keep some packages locally, following changes are in them... : This doesn't mean that I won't be considering patches from : non-maintainers. Pfew! : > Following are two patches, one (inline) for review (ignoring : > changes in whitespace) and one (attached) for easy application : > (``patch <gbs-loop-ispatch.patch'' in the src-directory.) : : FWIW, I can review attached patches just as easily as the inline ones -- : no need to duplicate the information. The change in indentation makes the ``ispatch()'' call hard to spot, hence the (botched) copy. : > Each of them does: : > : > *) Allow more than one argument at a time (e.g. do : > ``./boffo-1.0.36-1.sh prep conf build''). : > : > *) An ``ispatch'' command, copying a fresh patch, to make the porting : > process easier. (When you're done editing, do a : > ``./boffo-1.0.36-1 clean mkpatch ispatch finish all'' : > to get your new packages.) It backs up your old patch, to be on the : > safe side. : : I'm not clear on what the second part does. Could you please elaborate on : the purpose of "ispatch()"? Ok. Let me try to make this clear... You install the upstream package and a new gbs. you do a ``./boffo-x.y-1.sh prep'', cd into boffo-x.y and edit some files. You now do a ``./boffo-x.y-1.sh conf build'' and discover the build succeeds. A ``./boffo-x.y-1.sh check'' reveals it passes it's testsuite. You do a ``./boffo-x.y-1.sh clean mkpatch'' and look at the generated patch. It looks OK. You can then do `./boffo-x.y-1.sh ispatch'' to make sure you don't lose your edits when you remove the boffo-x.y-directory (e.g. by doing `./boffo-x.y-1.sh finish all''). In other words: ``ispatch'' copies the patch generated by ``mkpatch'' from .sinst to ${topdir}, so it can be used now, not just get included by ``spkg''. : > : We could also try putting some more : > : autodetection code into the GBS (e.g., get "make" to try both the "test" : > : rule and the "check" rule -- the two most common names for running the : > : testsuite -- and pick the one that exists). : > : > I saw a trick that might be usable for this somewhere... i'll get back : > to you on it... : : I think we could use something like "make -n" and check the return code... : But as I don't have the time to implement it properly now, I'll look at : whatever methods people choose to provide in their patches. It was something using a ``make -f -'' IIRC... (l8r) : > : I'm willing to coordinate the effort on this, but please everyone feel : > : free to send patches based on the above input. One major criterion for : > : accepting those patches would be to make the overall amount of changes to : > : the scripts smaller (with the secondary goal of making each individual set : > : of changes smaller). : > : > Should not the main objective be to make the needed effort (for : > understanding, maintaining, using effectively) smallest? (NRN) : : Well, not quite. The main objective, as far as I understood Chuck : Wilson's comments, was to be able to get a *new* package off the ground : fast. The GBS embodies several of the policies (e.g., the FHS, the : default configure arguments, the tarball filenames) which would otherwise : need to be taken care of. The more packages can be built with a minimal : (preferably empty) set of changes, the better. Understandability is : certainly an issue. Judging the needed effort, however, is very : subjective, so I'd prefer using the size of the necessary patch to : quantify it. Fair enough. Ny point was: Allowing multiple arguments, or auto- detecting various aspects, makes the patches bigger, but the gbs more useful. [append a (wrapped) GBS patch to the GBS] : > Would not that create an entirely new build method (with a very : > impractical structure)? : > : > Isn't it more in style with method 2 to store a copy of the gbs, : > before you made any mods to it, in CYGWIN-PATCHES? you can then : > always (diff out any changes you made/merge in changes from the : > latest cvs version). : : Huh? No, the GBS just gets edited -- I don't think it should go into : CYGWIN-PATCHES... It improves maintainability e.g. ``diff -u boffo-x.y/CYGWIN-PATCHES/gbs-orig boffo-x.y-1.sh'' and ``merge boffo-x.y-1.sh boffo-x.y/CYGWIN-PATCHES/gbs-orig cvsdir/gbs-new cp cvsdir/gbs-new boffo-x.y/CYGWIN-PATCHES/gbs-orig'' Or maybe just store the diff? One could then recreate the original gbs to merge against. [..] L8r, Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | / / really is | and false bits entirely. | mail for ) | | / / a 72 by 4 +-------------------------------+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe "s.u(z)\1.as." | me. 4^re