Alistair Crooks <agc%pkgsrc.org@localhost> 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