Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
Lucas Nussbaum dijo [Tue, Jan 18, 2011 at 08:27:22PM +0100]:
> > Heh, not the first time you push that way :)
> >
> > Still, I think the libfoo-ruby makes more sense when we are talking
> > about libraries. If an unexperienced user sees (picking a random
> > package of mine) a package called 'ruby-barby', with a slightly less
> > explicit description to what I have now (say, 'Barcode generation
> > tools'), he will probably install it and expect an application. Having
> > it called 'libbarby-ruby' makes it explicit it is a Ruby library. Of
> > course, the frameworks and applications should not follow this naming
> > scheme (as they are not just Ruby libraries).
>
> Except that we have some libfoo-ruby that ship binaries (it was the case
> for libgems-ruby, it's the case for librest-client-ruby). That causes
> a lot of confusion for the users, too.
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).
> > This could be efficient, but I'd like to keep having what we have now,
> > a single repository that carries all of the group's work, instead of
> > having a (very lightweight, yes, but uncoordinated) repository per
> > source package.
>
> Why would it have to be uncoordinated?
Because they are many different, separated repositories. Yes, they can
be coordinated by becoming submodules of a master Git tree - but I
think that'd be überclunk. I'm willing to be proven wrong, of course.
> So, we disagree on both (2) and (3). How do you suggest moving forward?
By reaching consensus ;-) Of course, I will just voice my points, but
try not to be stubborn with them. I can anticipate you this: You have
done far more work than me on Ruby. So, I'll end accepting what you
say, as you have more authority on this topic than me.
> > Well, building a package should always (in a perfect world) include
> > running its tests. Of course, build dependencies can be huge. But I
> > don't think it is _that_ bad. And assuming we all build using
> > pbuilder/cowbuilder (right? No, I don't always - but it is a factor
> > that would push me to the right practices!), it would basically just
> > mean a minor inconvenience.
>
> Sorry if it wasn't clear in my mail. The problem is that we are running
> into a dependency loop:
> package A requires B to run its test suite
> package B requires A to run its test suite
> which one should we package first, and how?
>
> The only way to break the loop is to avoid running the test suite when
> we first upload A, then upload B with the test suite enabled, then
> upload A.
Of course, before the involved libraries are all packaged, we will
have to skip some testing. But that would leave us no worse than how
we currently are, with very few tests being run - We can start filling
in the gaps gradually.
Reply to: