>> If you're going to bundle it, I'd rather us not fork it.  Keep it in
>> its own directory, and allow distros to rm -rf it, and add mini-tar
>> as
>> a dependency.
>>
>> http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries pretty
>> much sums up my thoughts on bundled libraries in general.
>>  Mcollective
>> is actually a decent example of bundling that is easily undone and
>> works for package maintainers.
>>
>
> +1, we discussed this in the past and everyone more or less decided
> mco is wrong how its done but really, its best :)

Thats a really nice pattern. For those who haven't seen it, look at
the effort required by distros to remove the vendored gem here:

http://anonscm.debian.org/gitweb/?p=pkg-puppet/mcollective.git;a=blob;f=debian/repackage.sh;h=ba20b289dc2ea3224701db327507b58f433396b2;hb=HEAD#l24

> the thing I need to do better in mco is write a package maintainers
> guide to make it clear to people how to undo the bundling as there's
> been some mistakes made where people just werent aware we did it this
> way but on the whole how mco does it worked out really well for us.
> The guide should be in the top level or in the top level README or
> something

Have we explored this at all within Puppet? What is the preferred
pattern in Puppet today, and do we see an advantage in adopting a
similar pattern?

ken.

-- 
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.

Reply via email to