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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
