[ On Tuesday, April 23, 2002 at 09:03:37 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: pkg/16460: make in pkgtools/pkg_install fails on old systems
>
> 
> 	I cvs updated pkgsrc to the NetBSD 1.4.1 system which did not
> 	have any packages installed beforehand. Then I tried to
> 	install the pkgtools/pkg_install. pkg_install decided it needs
> 	pkgtools/digest but registration of installation of
> 	pkgtools/digest fails because pkg_create does not understand
> 	the -S option.
> 
> How long are we supposed to support 1.4.1 in current pkgsrc? I think it
> would make sense to start drawing the line somewhere, say 1.4.3 and newer.

There are actually no problems yet with supporting even 1.3.x with
current pkgsrc.  I do it almost every working day (though I follow
current pkgsrc in jumps that may be as wide as several weeks).

$ uname -srm
NetBSD 1.3.2 sparc
$ /usr/sbin/pkg_info -I pkg_install
pkg_install-20010724 NetBSD-current's pkg_* tools
pkg_install-20000202 NetBSD-current's pkg_* tools
$ /usr/sbin/pkg_info -I digest      
digest-20010807     Message digest wrapper utility


$ uname -srm
NetBSD 1.3.3 i386
$ /usr/sbin/pkg_info -I pkg_install
pkg_install-20000202 NetBSD-current's pkg_* tools
pkg_install-20010724 NetBSD-current's pkg_* tools
$ /usr/sbin/pkg_info -I digest      
digest-20010320     message digest wrapper utility

(I don't want to do this any longer than necessary of course, but I must
consider many factors and account for many limitations that are not
under my direct control.)


It should be easy enough to have the underlying machinery install
pkg_install without having to have digest installed, and I thought
that's the way it worked.  Perhaps there's some point where pkg_install
was upgraded so that those of us following current pkgsrc were able to
get the new pkg_create before the digest thing appeared.

Let's see what's going on here.  All the digest and pkg_install version
check target names have "uptodate-" as their prefix:

	$ fgrep uptodate- bsd.pkg.mk
	uptodate-digest:
	uptodate-pkgtools: uptodate-zoularis
	uptodate-pkgtools:
	uptodate-zoularis:
	do-patch: uptodate-digest
	install: uptodate-pkgtools build ${INSTALL_COOKIE}
	package: uptodate-pkgtools install ${PACKAGE_COOKIE}
	replace: uptodate-pkgtools build real-replace
	undo-replace: uptodate-pkgtools real-undo-replace
	do-su-deinstall: uptodate-pkgtools
	info: uptodate-pkgtools
	check: uptodate-pkgtools
	makesum: fetch uptodate-digest
	makepatchsum mps: uptodate-digest
	checksum: fetch uptodate-digest
	# Install binary pkg, without strict uptodate-check first
	install-depends: uptodate-pkgtools

So if a user on an older system tries to do a build using current
pkgsrc, the first thing that'll trigger an uptodate-digest dependency
will be the checksum dependency.  This is necessary of course because
during the checksum target execution the digest tool will be used.

In the uptodate-digest check we see that the build rules, should it be
found to be out of date, are careful enough to avoid what is essentially
a dependency loop by checking if ${PKGNAME} matches "digest-*".

Now unfortunately the pkg_install build requires some patches.  This is
where the dilema begins.  If the pkg_install distribution came
pre-patched (and there's absolutely no reason why it can't since it's
created by the pkgsrc maintainers in the first place), then there would
be no effective dependency loop and the uptodate-digest rules could also
avoid the dependency loop if ${PKGNAME} also matches "pkg_install-*".
The final piece of the puzzle is to avoid the checksum dependency during
the build of pkg_install, which is of course easily done in several
different ways, though the best is by setting "NO_CHECKSUM=yes" in its
Makefile, which allows the user to do a manual checksum with the
following command:

	echo '.undef NO_CHECKSUM' | make -f Makefile -f - checksum

(I've always wanted a -U option for make, though the above trick suffices)

I think fixing this is important regardless of what release version
currently requires it.  This issue will undoutably arise again, if not
with these two tools then with something new we've not thought of yet.
A proper fix now will serve as a template to help ward off future
dependency loops.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>