On Tue, Apr 26, 2011 at 05:18:08PM +0200, Elimar Riesebieter wrote: > * Peter Pentchev [110426 15:49 +0300]: > > On Tue, Apr 26, 2011 at 01:38:02PM +0200, Elimar Riesebieter wrote: > > > Dear mentors, > > > > > > I am looking for a sponsor for the new version 3.9.0-2 > > > of my package "ripit". > > > > > > It builds these binary packages: > > > ripit - Textbased audio CD ripper > > > > > > This is an upload to unstable with no changes to the version which resides in > > > exparimental. > > > > I see that your package has already been uploaded; however, what do you > > think about the attached couple of patches - a couple of minor improvements > > and a couple of fixes to minor issues in the Debian packaging? None of them > > are mandatory or anything; they're just things that I would do to my own > > Debian packages, and of course it's up to you whether to accept them or not :) > > Well, those patches are not structured well. Come in come out. Why > not one patch per each file? Would be more comfortable to read. See below :) > And why do you prefer "dh $@"? Well, this is indeed a matter of preference, but by doing this I can easily keep track of what new programs are available in new versions of debhelper and I can easily start to use them. Of course, it helps that I also keep the last couple of build logs so they can be compared to the log from this run. Also, IMHO, a short and simple rules file is preferable to one that lists all of the commands actually invoked. Yes, there are arguments both ways - by listing the commands you know *exactly* what debhelper will do, but then it's a little bit harder to find out what is special about this particular package's build; by using override targets (or even dh --before, --until and --remaining) it's a lot easier to figure out how this package differs from the "usual" build procedure. Yes, with enough experience (and I dare say I may already have enough experience) it's *not so hard* to spot the differences even in an all-commands rules file, but... personally, to me, something like this: override_dh_auto_test: %: dh $@ ...screams "no, I don't want to run this package's test suite, even though I know it has one!" a bit louder than: build: build-stamp build-stamp: dh_testdir dh_auto_configure dh_auto_build touch build-stamp install: install-stamp install-stamp: build-stamp dh_testdir ... ...and so on :) As I said, a matter of preference, and that's the way I like it. > I'll pick up some hints but not all. Now *that*'s why I didn't structure them as "one patch per file" - so you could very easily pick only some of the changes and not the rest, without having to wonder whether this change in the rules file needs to go along with some other change in the control file, or whether the change in the compat file means that something will *have* to change in the rules file or else debhelper will do something nasty in the new compat mode... :) The patches are structured exactly in the sequence of commits - as a matter of fact, they *are* a series of Git commits done to a local repository that I created just for this purpose. The point was to make one commit per change, and when those commits touch more than one file, do it in one go. Of course, two changes in a row may touch the same file, but by keeping them separate, I give you a chance to evaluate each of them on its own merits. > Thanks > > Elimar No problem, and thanks for making Debian better by taking care of its packages! G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@FreeBSD.org peter@packetscale.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3?
Attachment:
signature.asc
Description: Digital signature