pkg_comp -- quick exit if pkg is installed already

[Ephaeton]

Hi there,

I've noticed a little annoyance for pkg_comp: if you give it a
list of packages that are installed already, it will a) try to
build these packages nonetheless, and b) note that this package
is "in error", because the install target failed. In fact everything
is fine though. This can be provoked two ways:
1) pkg_comp build (a package that is installed in chroot already)
2) pkg_comp build (list of package names including dependencies)

The first case is obvious, the second builds the dependencies as
required, but if your dependencies come later in the invocation
(say, you are taking the list of packages to build from a pkgchk.conf,
which is alphabetically sorted, not topologically) ... stuff "fails".

So, of course there's an easy solution:

--- files/pkg_comp.sh   2009-07-07 12:10:47.000000000 -0400
+++ /usr/pkg/sbin/pkg_comp      2009-11-03 07:39:35.000000000 -0500
@@ -730,11 +730,15 @@
         init_script $script
         cat >> $script <<EOF
 cd /usr/pkgsrc/$p
+if pkg_info -qe "\$(make show-var VARNAME=PKGNAME)" ; then
+       echo "PKG_COMP ==> $p already installed!"
+else
 make $BUILD_TARGET
 if [ \$? != 0 ]; then
     touch /pkg_comp/tmp/`basename $statfile`
 fi
 make clean
+fi
 EOF
         chmod +x $script
         chroot $DESTDIR /pkg_comp/tmp/`basename $script`

Do you agree? It helps for me :)

Regards,

-Martin

[Julio M. Merino Vidal-4]

On Tue, Nov 3, 2009 at 12:46 PM, Martin S. Weber <Ephaeton@...> wrote:

> Hi there,
>
> I've noticed a little annoyance for pkg_comp: if you give it a
> list of packages that are installed already, it will a) try to
> build these packages nonetheless, and b) note that this package
> is "in error", because the install target failed. In fact everything
> is fine though. This can be provoked two ways:
> 1) pkg_comp build (a package that is installed in chroot already)
> 2) pkg_comp build (list of package names including dependencies)
>
> The first case is obvious, the second builds the dependencies as
> required, but if your dependencies come later in the invocation
> (say, you are taking the list of packages to build from a pkgchk.conf,
> which is alphabetically sorted, not topologically) ... stuff "fails".

Yeah, 2 is pretty annoying.

> So, of course there's an easy solution:
[...]

Yeah, except this will not catch cases where the installed package is
older than the newest one.

I wouldn't bother with case 1.  But case 2 deserves fixing.  The only
problem with fixing 2 is that the real solution involves calculating
the whole list of packages to build and sorting them according to
their dependencies... which is not trivial to do from shell.

That said, I guess your fix helps more than it causes any harm.  So,
could you please file a PR with it, and include a diff to also bump
the package version number?

Thanks,

--
Julio Merino

[Ephaeton]

On Tue, Nov 03, 2009 at 01:06:02PM +0000, Julio Merino wrote:

> On Tue, Nov 3, 2009 at 12:46 PM, Martin S. Weber <Ephaeton@...> wrote:
> > Hi there,
> >
> > I've noticed a little annoyance for pkg_comp: if you give it a
> > list of packages that are installed already, it will a) try to
> > build these packages nonetheless, and b) note that this package
> > is "in error", because the install target failed. In fact everything
> > is fine though. This can be provoked two ways:
> > 1) pkg_comp build (a package that is installed in chroot already)
> > 2) pkg_comp build (list of package names including dependencies)
> >
> > The first case is obvious, the second builds the dependencies as
> > required, but if your dependencies come later in the invocation
> > (say, you are taking the list of packages to build from a pkgchk.conf,
> > which is alphabetically sorted, not topologically) ... stuff "fails".
>
> Yeah, 2 is pretty annoying.
>
> > So, of course there's an easy solution:
> [...]
>
> Yeah, except this will not catch cases where the installed package is
> older than the newest one.
>

Intentionally. I expect an error in that case: if I build binary packages
with pkg_comp I expect a binary package whose version matches that in
the underlying pkgsrc. I do want an error in that case. JMMV. Er. YMMV :)

> I wouldn't bother with case 1.  But case 2 deserves fixing.  The only
> problem with fixing 2 is that the real solution involves calculating
> the whole list of packages to build and sorting them according to
> their dependencies... which is not trivial to do from shell.

Hmm. I believe
http://mail-index.netbsd.org/tech-pkg/2005/05/04/0007.html
(scroll down to nearly the bottom of the message) should have a working
shell snippet for that ?

> That said, I guess your fix helps more than it causes any harm.  So,
> could you please file a PR with it, and include a diff to also bump
> the package version number?
>

Sure! (once back from work)

Regards,

-Martin