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. And, of course, it would be nice of you to distribute gemspecs, RPM specs, etc... inside the bundles. I think you already do this, so it's greatly appreciated! I suppose that you could bundle as gems, use gem2rpm, then alien and make everyone moderately sort of happy. Trevor On Wed, Feb 2, 2011 at 1:37 AM, Luke Kanies <[email protected]> wrote: > On Feb 1, 2011, at 7:55 PM, Michael Stahnke wrote: > >>> Pains me to say this but Gems are designed to solve these problems cos >>> you can have many versions on a machine and each project can require >>> the version they wish. >>> >>> I'd favor some way to vendor them into our projects so we can maintain >>> the one we care about internally to each project and upgrade when we're >>> ready. >>> >> >> Keep in mind it's often times against package guidelines to ship items >> that have been 'vendored'. From a systems management perspective, >> it's the equivalent to static linking binaries. If Puppet started >> vendoring its dependencies, then EPEL for example, would have to >> un-vendor them in order to package it for enterprise Linux. It's a >> slippery slope. >> >> I would still be in favor of code reuse, just not so much the >> vendoring part. Breaking puppet into smaller components is fine. > > Yeah, I agree with this basic question - how do we achieve code reuse without > just vendoring things? > > The only choice I see is to fully package everything we want treated like a > dependency. That kind of sucks for a lot of things I'm thinking of, though. > E.g., I'd love to pull Puppet::Application and my prototype Puppet::Interface > code into a separate repo so facter, puppet, mcollective, etc could all > depend on it, but it's going to end up being quite small, so that doesn't > really work. > > 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. > > I think this is ugly, but is it more ugly than having 10 teeny packages that > now need to get added to Debian, Red Hat, etc? > > 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. > > -- > I believe that if it were left to artists to choose their own labels, > most would choose none. -- Ben Shahn > --------------------------------------------------------------------- > 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. > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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.
