Testing wanted: pkgmk with --ignore-new option

Johannes Winkelmann jw at smts.ch
Sun Mar 8 10:25:02 UTC 2009


Hi there,

On Sun, Mar 08, 2009 at 18:21:09 +1100, lucas at die.net.au wrote:
> On Sat, Mar 07, 2009 at 03:32:37PM +0100, Predrag Ivanovic wrote:
> > On Wed, 04 Mar 2009 19:08:28 +0100
> > Johannes Winkelmann wrote:
> > 
> > >Hi there,
> > >
> > >I've done an update to pkgmk to add symbolic error codes (fairly coarse
> > >for now), and to optionally ignore footprint missmatches if no files are
> > >missing (also see bug #221 for more information on this).
> > 
> > Pkgmk that Han Boetes modified few years back (which I use without
> > problems so far), has something similar wrt footprint mismatches
> > (and a few extra goodies that made my life when making ports a bit
> > easier :) )
> > 
> > I always wondered why vanilla pkgmk doesn't have something similar,
> > I'm glad to see that it might get such a usefull, imho,
> > feature.Default 'throw an error, remove all' behaviour always seemed
> > a bit abrupt to me, not to mention frustrating when I made a typo in
> > Pkgfile or forgot to remove some junk file, and pkgmk happily
> > deletes both source and built package that took an hour to
> > compile(that was the default behaviour, iirc).
Well, pkgmk only removes src/pkg files when one asks for it (using the
'-c/--clean' option), so in normal operation this should never happen.
Of course, if there's a build error like the typo in the Pkgfile you
mention, no package is created in the first place. To me, this seems the
right behaviour, since this only happens during the packaging phase,
where we don't want to provide too many shortcuts to avoid problems for
the users later on.

In case of footprint mismatches which this patch addresses, the package
file is always kept and can be pkgadd'ed if the user is "happy" with the
mismatch. The problem so far was that there was no way for tools like
prt-get to know that a footprint mismatch happened, and thus it could
not ask the user to review it, similar to Han's pkgutils. Also, there
was no distinction between "only new files" mismatches (the ones which
are typically caused by optional dependencies) and mixed "new/missing"
mismatches (which should typically be looked at).

Now, the patch did not add this distinction either but added a flag to
treat "only new" mismatches as non-error, but maybe it would be better
to return an error anyway, and let the caller (user or tools) take this
decision. I'll have to think about this a bit more though.


> > Oh, memories, memories
> > ;) I'm sure you'll come up with some nice/elegant/usefull solution,
> > Johannes, you have pretty good track record so far :) 
Thanks for your trust :-)


> The reason is simple, unattended installs. The last thing I want is my
> package manager sitting around waiting for me to tell it what to
> do until it attempts to compile the next package. Failing the way it
> does, it the simplest (and imho best) way to do it.
Yeah, this is important to me as well. However if pkgmk has better
return values, there's still the possibiliy to implement (optional)
interactive modes in tools.


Somehow related, I was wondering if lack of md5sum and footprint files
should be considered an error; I think it should. These files should be
created only during packaging, but not when building packages from a
published ports tree. Opinions?


Cheers, Johannes
-- 
Johannes Winkelmann              mailto:jw at smts.ch
Zurich, Switzerland              http://jw.smts.ch



More information about the CRUX mailing list