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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
