Re: Various size of (Project) ideas for NetBSD and pkgsrc

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Wed, Oct 02, 2013 at 12:26:08AM +0200, Pierre Pronchery wrote:
>                       Hi all,
> 
> On 30/09/2013 04:26, Alistair Crooks wrote:
> > 
> > On Sun, Sep 29, 2013 at 10:09:53AM +0900, Ryo ONODERA wrote:
> >> (2) Create multiple packages from one pkgsrc package directory
> >> For example, pkgsrc/fonts/harfbuzz has icu option and theoretically
> >> non-icu part and icu part can be separate package, but splitting
> >> only icu part from harfbuzz is difficult in configure/build stage.
> >> In rpm (Red Hat package manager) case, "build once and multiple packages is
> >> created" is realized with custom do-install target.
> >> "build once" means reduce of build time.
> > 
> > The way I see it, if I as a normal user wants to build a package, I
> > know what options I want, and have them set already ahead of time.
> > Having two separate binary packages with different options on the same
> > machine is an unusual use case, and not something I'd recommend from
> > a tearing hair out PoV. And if it's meant for the bulk builders, then
> > this is usually done on larger machines, where any gain would be minimal.
> 
> I think there's are a number of interesting use cases for generating
> multiple binary packages out of single source directories.
> 
> The most obvious one is like most distributions do, to
> (semi-)automatically separate development from documentation from
> essential files. In the case of glib2, this could be "glib2-lib",
> "glib2-dev", "glib2-doc", and then "glib2" (for the remaining binaries).
> I am not particularly fond of this separation, but it can make a lot of
> sense for binary deployments, particularly so on embedded platforms.

Yes, IKWYM, but then you will have to specify multiple PLISTs for each
of the different sub-packages that you build.  So now that we have a
separate functional description of the subpackage, you'll need a
separate DESCR, too.  And it would be better to split the monolithic
Makefile up, too, so that it's modular for each functional
sub-package. And, as you note later on, non-trivial changes to the
pkgsrc mk insfrastructure.

Once you've done that, and put each functional part into its own
directory, you have exactly the same situation that we have at the
moment.  Minus any huffing and puffing with the pkgsrc mk
infrastructure. So, I'm struggling to see where the benefit lies.

We've always tried to take a sane approach to this kind of split.
And the options framework came along, and that kind of thing was
deemed unnecessary.

The canonical example was always Debian, which had 27 packages for
boost (pkgsrc has 7, which I think is much more manageable). I have
no idea if this is still the case for Debian.

> Then, there is the case of packages providing optional files, such as
> plug-ins. It is faster to build these packages only once, and then split
> them in, say, "make package". Tracking dependencies per sub-package can
> also be very helpful for binary distribution in this case.

In the past we've always split that kind of thing into their own
directory, explicitly, and made them into their own package.  This
simplifies the "semi-automatic" part that you didn't mention above,
plus making first class citizens of the binary packages which provide
the plugins.
 
> With this said, this would certainly involve quite some work...

Non-trivial work, for little (I'm being nice, I can't see any
whatsoever) gain.  No-one has yet been able to tell me what the gains
are to this approach, only that the approach is possible.

Best,
Alistair