On Feb 2, 2011, at 10:26 AM, Michael Stahnke wrote: > On Wed, Feb 2, 2011 at 8:44 AM, Trevor Vaughan <[email protected]> wrote: >> I don't see any issue with the 10 or so dependencies that get added to >> Debian, Red Hat, et. al.. >> >> From an administration perspective, I actually like this, it lets me >> know *exactly* what is going on my system and why. I definitely do not >> like the idea of having a bunch of projects all in different spaces >> blown out via one package. >> >> That said, I don't see any reason why a given package can't include >> the rest of the items so long as they cannot run separately. >> >> If they can run separately, they should be a different package. > > This is fine for package guidelines as far as EPEL/RHEL/Fedora goes, > and I believe Debian as well. Having many small packages isn't much > of an issue. Specifically if you want mcollective, puppet, facter and > more to rely on some of this library code, I think creating small > packages, and ensuring dependencies are properly referenced is fine.
This is basically what I was thinking - something that would be installed into the repo under each repo's name space. >> I suppose that you could bundle as gems, use gem2rpm, then alien and >> make everyone moderately sort of happy. > > For very odd definitions of happy. > >>> For very small systems (I'd expect this to consist of two files) it could >>> possibly work to >>> have a rake task that installs the libs into the different repos, so it >>> resembles vendoring >>but done in a way that the classes get renamed and >>> everything. > > This sounds interesting, but certainly not the simplest thing that > could possibly work. What else would work? >>> It's the low dependency count that really kills us - we don't want any >>> further external >>dependencies, but that's pretty much at odds with code >>> sharing, at least in so far as I can >>see a solution. > > Are they really external dependencies if something that in the package > is not in puppet-libs or puppet-ai-libs ? The only real change I see > is the package count, and possibly the effort to get the package > changes and builds through the various review obstacles to get intro a > downstream distro. I've always maintained Puppet on the assumption that keeping a low dependency count was critical - other than ruby itself, the only required dependency for Puppet is Facter. It might be, though, that our community has grown to the point where new dependencies aren't nearly as costly. One of the reasons I'm thinking these things don't really justify external dependencies is that they're probably just going to be libraries, and very small ones at that. The things I can think of right now that might be useful would be SimpleGraph, Application and Interface (which only exists in my data_app branch), and maybe the SSL stuff. -- Levy's Law: The truth is always more interesting than your preconception of what it might be. --------------------------------------------------------------------- Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
