Johnny C. Lam wrote:
> What I've mentioned above will be done over the next week or two, but
> there is another part of this project which is somewhat controversial,
> and I'd like to get some feedback on it.  In my mind, pkgsrc does two
> separate and distinct things, even though we just call the whole thing
> "pkgsrc" -- pkgsrc is a system to build software, and pkgsrc is a
> system to manage software.  I would like to leverage our strength in
> making software build on lots of different platforms, and then allow
> installing and packaging software in the platform's "native" package
> format.  For example, this would be "SVR4 package format" on Solaris,
> or RPM on Red Hat and SuSE, and of course, "pkgsrc format" will always
> be supported by default for all platforms.  I note that there is a
> pkgtools/gensolpkg package written by Alistair Crooks which points
> the way do this for SVR4 packages on Solaris, so this project is
> clearly doable.

I like this. I like this a lot.

>   * It would be possible to create repositories of binary packages in
>     the platform's native format which can be installed without needing
>     to install a bootstrap kit.

I can see this as being a major win in some circles. For example,
providing builds of packages for Solaris in its native packaging format
would virtually overnight be able to provide a larger package repository
than blastwave.org.

> The following are what I see as negatives of this proposal:
> 
>   * It's a disincentive to improve pkgsrc's package management tools.
>     We'll certainly keep improving them for the sake of NetBSD and
>     DragonFly, but we may lose testing from Linux and Solaris users.

I don't think I see it that way.

I expect that the number of Linux / Solaris users will increase as a
result, and that some will choose host package format, and that some
will choose pkgsrc format. And the incentive will be there for pkgsrc to
be able to offer something in its package management tools that isn't in
the "host" tools.

> Through my investigations within pkgsrc/mk, I believe that the relevant
> parts of the package workflow which would be affected by this are
> "install-depends", "install", and "package".  As part of my project to
> split out "install" and "package" into separate modules, I'd like to
> re-implement them with the idea of extending them to initially support
> "pkgsrc" and "SVR4 package" formats.

Do you expect to be able to fully handle the install scripts and all the
other current magic that pkgsrc does (creating users, etc), in SVR4
packages?

-- 
Gillette - the best a man can forget