tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "doc" option

Alistair Crooks <> writes:

> I'd really like to see the evaluation of some other approaches before
> any changes are made.

The problem is that all the other options are either hard, or they
require building the whole package and then splitting it.

> dillo talked about sub-packages in the past.  I
> haven't ever seen a design document, but I'm sure there's one flying
> about.  In pkgsrc, we've also split into separate packages in the past
> to avoid circular dependencies, which Greg notes was a net loss,
> although I'd be more interested in seeing why, as it's the way Debian
> packages operate usually (they used to have 27 separate packages for
> boost).

Debian (and rest of GNU/Linux) is different than our split packages.
IIUC, they build the entire package, requiring the union of
dependencies, and then split the resulting bits into multiple binary
packges.  In a world where users only install binaries and only install
things, that works great.  In pkgsrc it fails to avoid the pain of
needing the dependencies installed for a user to build.

pkgsrc split packages (amanda, gimp-print-lib are examples) either use
--enable options provided by upstream (eg. gnuradio) which is great, or
hack makefiles, which is a lot of work, and has to be redone a lot on
updates.  Compare gimp-print-* and gutenprint and see why I gave up :-)

> I've been mulling over the idea of filtering binary packages
> at package install time, along with modification of PLISTs. I'm not
> sure how effective this would be, but it would be the least intrusive
> on the build side.

It would solve half the problem, and that's progress.  But I don't think
it addresses the pain people have needing tex/xml to build simple
packages on minimal machines.

Attachment: pgpz2LTA553Ru.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index