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

Re: CDBS and dh_install

Bundling up a few replies here...

On Sat, Jun 10, 2006 at 10:02:26AM +0300, George Danchev wrote:

> I'm also debhelper fan ;-) but what makes you think that if you face a 
> problematic debhelper script you are not supposed to reimplement that 
> particular part of rules by hand as an interim workaround ?

I don't think I implied that it wouldn't be appropriate to do this --
actually, my point is precisely that there's a big gap in the *difficulty*
of doing this for debhelper vs. cdbs.  For debhelper, you delete one line
and replace it with a very small shell script.  For cdbs, you delete one
line and have to replace it with your reimplementation of a very large

On Sat, Jun 10, 2006 at 10:39:32AM +0200, Thomas Weber wrote:
> first off, I'm neither a DD nor an NM, but I do some packaging work
> (thanks to alioth), As most people here argue against CDBS, I think the
> benefits of it are missed (if you didn't guess, I use it and I like it).

Oh, I disagree; I think I have a pretty good idea what the benefits are of
CDBS, I just think that many CDBS proponents underemphasize the *downside*
of CDBS.

> Am Freitag, den 09.06.2006, 15:10 -0700 schrieb Steve Langasek:
> > On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:
> > > > This is also my impression. CDBS might be nice to automate the task
> > > > "make a .deb out of this Gnome source", but imho it completely fails
> > > > when you want to deviate from the "standard" in any way.

> I guess this paragraph sums it up pretty good. CDBS is not the best
> choice if you need something  *not* _c_ommon. OTOH, if I see a CDBS
> based rules files with three lines, this tells me one thing pretty
> clearly: there's nothing unusual in this package.

So tell me, how do you know a priori whether the software you're packaging
is going to be "common", or if it's going to need to deviate from CDBS at
some point in the future?  If you're recommending a packaging style to a new
packager who probably doesn't have the level of committment to learn more
than a single helper style, how do you know whether they will at some point
need to package something that doesn't fit in cdbs's neat little view of the

> > Let's compare debhelper to cdbs.
> I don't quite agree with your analysis. If you say "CDBS stuff is
> under /usr/share/cdbs", you must as well say "dh_* stuff is
> under /usr/share/perl5/Debian/Debhelper/". 

I was pointing out that you can't learn anything about what cdbs does by
looking at the debian/rules of a package that uses it.  If I have a
debian/rules file that invokes a command, and I don't understand what that
command does, I can look at the manpage.  If I have a debian/rules file that
includes other makefiles, my choices are to look at the include file itself
and study it (for which the *shortest* of these is as long as the stock
dh-make template rules file), or track down the cdbs documentation... which
in at least one noteworthy case tells me to go look at the include files
anyway (hee).

I dunno, maybe my work habits mean I'm missing out on some great IDE
features that make it non-painful to track through makefile includes, but
for me, about the second time I find myself typing /usr/share/ to look at a
file in order to understand what a package is doing, I start to get a little
grumpy about it. :)

> The problem is the documentation, which leaves room for improvement. I
> mean, how many people would understand dh_* without the manpages?

Er... is that really meant to be a defense of CDBS?  debhelper *does* have
manpages, and this is an important part of why I think it's better.

> I mean, if I want default values for a program, I do "./configure" and
> not "./configure --enable-default-prefix --enable-default-docpath ..."

Hmm, interesting comparison, given all the arguments that cdbs itself passes
to ./configure by default:

  --build=$(DEB_BUILD_GNU_TYPE) --prefix=$(DEB_CONFIGURE_PREFIX) \
  --includedir=$(DEB_CONFIGURE_INCLUDEDIR) \
  --sysconfdir=$(DEB_CONFIGURE_SYSCONFDIR) \
  --localstatedir=$(DEB_CONFIGURE_LOCALSTATEDIR) \
  --libexecdir=$(DEB_CONFIGURE_LIBEXECDIR) --disable-maintainer-mode \


On Sat, Jun 10, 2006 at 11:08:15AM +0200, Loïc Minier wrote:
>  You are looking at the individual dh_* commands, but:
>  - the precise list of debhelper calls varies from package to package,
>    there's nothing standard or documented in this
>  - the order of the debhelper calls varies from package to package

What problems does this cause?  I mean, I've heard of a few bugs from time
to time caused by maintainers putting key debhelper commands out of order;
but I've seen the same sort of thing happen to cdbs-using packages too, and
I don't see that having such slight variations in debian/rules files
seriously harming comprehension.

>  Compare with CDBS where the list of debhelper calls has some order
>  constraints and where the list itself can evolve: introduction of
>  dh_gconf in the rules used by GNOME packages is only a matter of adding
>  the call to the relevant CDBS file, not to each individual package.

The flip side of this is that the behavior of cdbs-using packages is always
changing, without the knowledge or control of the package maintainer.  E.g.,
while I was drafting this message,
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372273;msg=10> showed up
in my mailbox...

>  I agree that it's a nice feature to be able to say dh_install conforms
>  to its documentation, yet the same feature is available in CDBS which
>  calls dh_install: the precise dh_install call will happen from CDBS
>  instead of directly from your debian/rules, but you have the same
>  documentation, and interface to write your debian/*.install files.

But I, as a package maintainer, can't actually depend on the dh_install
interface if I use cdbs because *I'm* not using dh_install.  My interface is
"include /usr/share/cdbs/1/rules/debhelper.mk", for which no specific
behavior is defined -- the behavior is simply "do whatever debhelper-related
packaging operations that the maintainers of cdbs thought was appropriate
when this version of cdbs was packaged", and as we see, this has definitely
changed over time.

>  Agreed, documentation is a bit lacking and could be improved.  More
>  importantly, the interface is not as clearly defined as a command call,
>  because Makefiles allow much more.  I can't imagine what to put in a
>  simple-patchsys.mk man page, or it would be as long as the original
>  makefile.

No, clearly makefile includes shouldn't have manpages; but some kind of
documentation that tells cdbs users what they should or shouldn't be able to
depend on would be a good idea.  In the absence of such documentation I
think the current answer to what they can depend on is actually "very
little", which is a big part of why I don't encourage its use.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: