Re: RFC: How to organize guile-gnome

[Greg Troxel]

  > This is a cool feature, but pkgsrc unfortunately doesn't have it.  The
  > basic approach is to build a package, install all or some of it, and
  > then package up the resulting installed files.  Thus my plea for the
  > ability to install in chunks (rather than everything up to and
  > including some point).

  This is not a huge problem. We can make configure take --only-modules=
  arguments, or something. All of this can be done with clever autotools.
  It's just a matter of making it clever *and* passing `make distcheck' ;)

That sounds like a good plan.


  So again, it's possible. Personally, I'm not going to do a lot of work
  to support what I consider to be broken package managers; if you want to
  build from source, it should be easy, and if you want to install
  packages, it should be easy. But we can throw in some auto-foo to help
  you out if it's necessary.

It's not helping me out as making it more likely that guile stuff will
be included as packages on systems that use pkgsrc and pkgsrc-like
mechanisms.  But the above --only-modules= plan sounds great.

Pkgsrc is definitely deficient for not being able to split packages
into components at build time.  A key area where this is useful is
splitting libraries  into base and dev parts.

But the situation is more complicated than that; consider building a
package for a source tarball that can support 50 optional libraries
(to wrap).  It's not reasonable to require all 50 to be installed to
build the package, even if 50 separately installable packages (plus 1
base) are built.  Part of the pkgsrc mentality, derived from the large
numbers of OSs supported (7) and architectures (hard to count, but at
least 20), is that it is normal for users to build from pkgsrc, not
just install binary packages.  For these users, depending on the 50
libraries is unreasonable; they should be able to build the parts they
need using the package system (rather than a by-hand build),
particularly since for many this will be an automatically built
dependency from something else.

Does the Debian package system handle this case (other than by
requiring package builders to have all possible dependencies
installed)?  Perhaps it can only construct "package splits" for those
sets that get all of their files created from the build that happens.

pkgsrc can support conditional defines to not build with some features
(e.g no IPv6 in zebra/quagga).  But this leads to not being able to
install cleanly the package with more features later.

But I see your point about this being perhaps difficult to support;
I'll see if I can help out with this at some point instead of just
flaming on the list.
                                                   
-- 
        Greg Troxel <address@hidden>