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
Hi there, On Sun, Mar 08, 2009 at 18:21:09 +1100, lucas@die.net.au wrote: 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@smts.ch Zurich, Switzerland http://jw.smts.ch