Subject: Re: [HEADS UP] pkg_install pullup
To: Joerg Sonnenberger <joerg@britannica.bec.de>
From: Greg A. Woods <woods@planix.com>
List: netbsd-users
Date: 07/11/2007 00:47:06
--pgp-sign-Multipart_Wed_Jul_11_00:47:04_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Wed, 11 Jul 2007 01:22:47 +0200, Joerg Sonnenberger wrote:
Subject: [HEADS UP] pkg_install pullup
>=20
> Already removed in the current version are:
> - part of the backend to support multiple @cwd directives
> - pkg_create doesn't allow require scripts any longer, support in
> pkg_add and pkg_info will be removed at a later point.n

That's not a good idea.  Why remove a VERY useful feature?

I was actually working on patches to submit to reinstate support for
requirements scripts not only to pkg_install, but to pkgsrc itself.  I
have found them to be useful for a couple of purposes even within pkgsrc
itself, and they are potentially very useful for managing binary
packages in production environments, i.e. for custom environments over
and above using pkgsrc alone.


> - pkg_create -h and -X were dropped

I'm not so sure it's a good idea to remove those features either.

> To be removed soon:
> - support for master/slave mode=20
> - pkg_create -l, either to be made the default or not
> - pkg_create -m and corresponding code in pkg_add later, this was
> retired after the 2007Q2 branch.

Again, it is NOT a good idea to remove any of these features!

Just because pkgsrc doesn't need a given feature of pkg_install doesn't
mean those features should be, or even need to be, removed, especially
not from the package management tool supplied with the base OS.

Also, why remove any features when doing so will break compatibility
with all other existing variants of pkg_install, including the ultimate
origin variant?  Has any of this even been discussed with FreeBSD or any
other OS project or open-souce package management project using a
variant of pkg_install?

Until now third party developers could more or less depend on the common
features of pkg_install on all systems.  Now, already, NetBSD (all of
NetBSD, not just pkgsrc) will be the odd man out and we'll need a proper
pkg_install pkg for one or more of the other variants just to get that
compatibility back.  More twisty passages all alike seem to have to be
added to the maze ever more frequently.

Note that as recently as FreeBSD-5.4 there have even been further
enhancements made to the support for requirements scripts in FreeBSD's
pkg_install.  It's not a dying feature.


> In general, pkg_create is considered to be a backend for pkgsrc and will
> be changed accordingly.

pkg_create is the creator of inputs to pkg_add for _everyone_ who
creates binary packages.  It is not just a private utility of pkgsrc!

The relatively narrow views of pkgsrc are _not_ a very good way of
defining, and especially not of limiting, the more general requirements
of a full binary package management tool!



More generally speaking I find it's bad enough when code originated in
one of the *BSDs and used in the others begins to diverge internally
with different fixes, and other less subtle implementation differences
between the *BSD and other platforms now maintaining their own variants;
but when major utilities with such derivations begin to diverge wildly
at the user interface level, well then it's really sad, and for no good
reason whatsoever.


If NetBSD were to follow its own guidelines for things like pkg_install
which are properly third-party code then even for pkgsrc the new options
and features, as well as all fixes of course, would have been proposed
and fed back to the original maintainers before ever being relied upon
for a full NetBSD release.  Why isn't NetBSD simply feeding pkg_install
fixes and features back to FreeBSD and then re-importing the updated
FreeBSD source at regular intervals?  There are tons of fixes that
should be merged both ways now, never mind features.  Sigh.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Wed_Jul_11_00:47:04_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: zrz35LN8aU/ZiO0xN/v70kqq3FtH5Ko8

iQA/AwUBRpRgyGZ9cbd4v/R/EQLUrACfUX/2heL37WPBr4X7pw5a3iqCalQAoM4F
s1LKUKjkXZnfHxSBS8/L6oiH
=dCIN
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Jul_11_00:47:04_2007-1--