[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: ripit (updated package, upload to unstable only)

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:


	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
	touch build-stamp

install:	install-stamp
install-stamp:	build-stamp
...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


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

Reply to: