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

Re: CDBS and dh_install



Am Samstag, den 10.06.2006, 15:38 -0700 schrieb Steve Langasek:
> 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.
> 
> 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?  

Well, how do I know if I have to deviate from the debhelper scripts at
some point in the future? In fact, if I bump up the compat level, I
might very well need to change my scripts.

The difference is that joey is extremely careful not to break things
(and debhelper scripts are already quite mature).


> 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
> world?
I don't know it, but that's not the problem. CDBS is for the simple
cases where its neat little view is fulfilled. I believe a large number
of packages in Debian fit in this little view. Does it really make sense
to have long rules files for these packages? I believe packagers' time
is better spent on complicated packages, where CDBS isn't enough.

NM's using only CDBS will probably fail. 



> 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.
It wasn't meant as a defense. Now, we have (basically) two choices: dump
CDBS or improve the docs.


> > 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) \
>   --mandir=$(DEB_CONFIGURE_MANDIR) --infodir=$(DEB_CONFIGURE_INFODIR) \
>   --sysconfdir=$(DEB_CONFIGURE_SYSCONFDIR) \
>   --localstatedir=$(DEB_CONFIGURE_LOCALSTATEDIR) \
>   --libexecdir=$(DEB_CONFIGURE_LIBEXECDIR) --disable-maintainer-mode \
>   --disable-dependency-tracking
> 
> :)
Yes, but I don't need to type this stuff myself (and it's there if I
need to override it) in dozens of packages.


> 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;
The right order surely was documented :)
But we all know (at least those with end user experience) that people
never read docs -- so why bother writing them? :)


Regards
	Thomas



Reply to: