Re: ITP: libcmd-ruby -- library for building line-oriented command interpreters in Ruby
On Wed, Apr 13, 2005 at 01:05:25PM -0400, David Nusinow wrote:
> Note: I have an ITP open on libformatr-ruby (#295171) and both this
> library and formatr are very small, so I am hesitant to put them in
> their own packages. I plan instead to create an aggregate package
> (libruby-extras or something) with non-standard ruby libs that are
> helpful.
I wouldn't do that.
Do these have different upstreams?
Do these have different release cycles?
Aggregating upstreams has the disadvantage that one upstream update
means upgrading a whole bunch of stuff en masse.
For example, I reallly really really hate the current rails packaging
in Debian. The "rails" package actually bundles at least five
different things. This might be a good thing from upstream's (rather
limited and short sighted) point of view but sort of defeats the
purpose of having a good package manager to work with. Upstream's
reasoning, as far as I been able to grasp it, mainly focuses on
Microsoft Windows environments and the very brain-damaged packaging
system that's ruby gems. The rails package contains stuff that very
useful on its own, but from the POV of rails it's just a little
nuissanse. This doesn't mean that you can't just install "rails" and
use the useful stuff, you can (even if it's "hidden" in
/usr/share/rails), but as times goes forward, "rails" pulls in more and
more unwanted stuff.
Marcelo
Reply to: