On Wed, Jul 11, 2007 at 12:47:06AM -0400, Greg A. Woods wrote:
> At Wed, 11 Jul 2007 01:22:47 +0200, Joerg Sonnenberger wrote:
> Subject: [HEADS UP] pkg_install pullup
> > 
> > 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?

Because it is redundant. The install script is called twice, once for
pre-install mode, once for post-install mode. If it returns
un-successful in the pre-install phase, the full installation is
stopped.

> > - pkg_create -h and -X were dropped
> 
> I'm not so sure it's a good idea to remove those features either.

The PLIST can be filtered to get the result of -X and -h seriously
breaks too many things to be useful.

> > To be removed soon:
> > - support for master/slave mode 
> > - 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!

They are complete unused. The master/slave mode was *NEVER* used,
neither for pkgsrc nor for ports. The only practical area where it might
be helpful is installation into sub-directory (DESTDIR mode similiar to
installworld). That can be done much easier and will be part of the
commit that removes master/slave mode and drops the external tar
invocation. Keeping this around means a lot of useless code to convert
and I don't see a valid reason for such a maintainance mess. I can't
even test is without creating my own test suite yet.

> 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?

Being compatible was irrelevant for ages.

> 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.

Sorry, but I'll laugh when I have more time. pkg_install of FreeBSD and
NetBSD have diverted so much over the years. pkg_install might have
started in FreeBSD, but so did pkgsrc as fork of ports. You know that
the former has barely anything in common with FreeBSD ports any more?

I haven't seen a good reason yet and just arguing that "we have to be
compatible to FreeBSD" is something I'm very willing to ignore if it
means I can improve the life for the rest of the NetBSD and pkgsrc
users.

Joerg