Naming of source and binary packages (Was: Ruby packaging in wheezy: gem2deb, new policy, etc.)
- To: debian-ruby@lists.debian.org
- Subject: Naming of source and binary packages (Was: Ruby packaging in wheezy: gem2deb, new policy, etc.)
- From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
- Date: Sun, 27 Feb 2011 09:25:42 +0100
- Message-id: <20110227082542.GA14279@xanadu.blop.info>
- In-reply-to: <20110119185625.GF4574@gwolf.org>
- References: <20110116224924.GA13341@xanadu.blop.info> <20110118182603.GI30470@gwolf.org> <20110118192722.GA13760@xanadu.blop.info> <20110119185625.GF4574@gwolf.org>
Hi,
I'm resurecting this subthread to discuss the naming of packages.
On 19/01/11 at 12:56 -0600, Gunnar Wolf wrote:
> Agree. And maybe it's overkill to separate just the library from an
> eight line long program (the case of haml, sass, html2haml, css2sass,
> ...) to keep things clean. But OTOH, here it would be worth analyzing
> what are we aiming at with each individual package - I picked
> libhaml-ruby as an example, so:
>
> - Is it a library? If so, it deservers having the 'ruby' particle in
> the name. And IMO it benefits from being ^lib, as it is clearer
>
> - Is it an application? Yes, users can benefit from manually
> converting between HTML and HAML from the command-line. If used so,
> and being a bit overzealous on Policy 10.4, users should not care
> what language it is implemented in - So the package could just be
> called 'haml', not 'ruby-haml'.
>
> - Does it have both? It can/should(?) be split into just the libraries
> (libhaml-ruby) and the executables (haml, which incidentally happens
> to be implemented in Ruby).
Regarding library-only packages (an example is nokogiri), I think that
we should go for binary package ruby-nokogiri, for various reasons given
in that thread, and I think that the consensus is against keeping the
current lib.*-ruby naming convention.
Now, there are more problems to solve:
1) organization of binary packages for source packages that mix
libraries and applications
If the main use of the software is as a library, and the binaries are
only there as support, it makes sense to stick with ruby-*.
If, instead, the main use is as application, we could drop "ruby-".
And if unsure, ask the list ;)
That would result in packages named:
chef
rails
rubygems
puppet
...
Useless splits with several binary packages should be avoided. For
example, if shipping the binary with the library adds less than 20% to
the size of the library package, the packages should be merged.
2) naming of source packages
I think that we should get rid of lib.*-ruby source packages, even if
that means slightly more work for us.
And to replace them, I think that packages should be named the same as
the main binary package for the package. So ruby-*, or directly "chef",
"puppet", etc.
Comments?
I *think* that those are the last points to discuss before we can send
the wiki page to debian-devel@ and ask for comments.
- Lucas
Reply to: