Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski in
<Pine.GSO.4.58.0406180839470.3356@slinky.cs.nyu.edu>:
: 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