Re: CDBS and dh_install
#include <hallo.h>
* Marc Dequènes [Sun, Jun 11 2006, 03:00:12AM]:
> > 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
> > makefile...
>
> That's obvious because CDBS does not target at doing little independent
> tasks (even if some may be *perhaps* be transformed to dh_*), but to
> autogenerate rules. CDBS is a layer over debhelper, this cannot be
> simply compared this way.
Yes. And you rely completely on CDBS doing some automagick and do the
right thing. But... oh wonder, somehow most of my packages do not fit
into this pattern of "./configure && make && make install && PARTY!".
> > 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.
>
> That's not true for everybody. The auto control generation is now never
> run automatically because we agreed it could cause harm.
Why could you, oh why? you do not trust the God Of Autoscripting any
more? You bastards!!!!1
> You simply don't care about this...
And when I _need_ to care about this because sth. does not work?
> If something is missing or inadéquate you juste hook on makefile rules
> and add your own commands (debhelper if necessary). you can even stop
"Just Hook", aha. You can say that if you know all the variables and the
internal dependencies.
> including some classes and reimplement what is uncommon and thus has no
> reason to be in a class. I never found any package being fully uncommon,
> so i see no reason not to use CDBS if you feel well with this tool with
> any package..
>
> If the packager has no time to learn Debian tools correctly, then he
There are tools, and there are tools. Debhelper tools are usualy easy to
understand (at least what they exactly do) and to work around in case of
failure, but CDBS is a complex code hell.
> must not be sent to NM, or must not be accepted by AM or DAM, that's
> really obvious. People willing to have a @debian.org email for fun or
> unwilling to learn and work seriously can just can become MOTUs...
> What would you say if i told you i had not yet time to learn how the
> BTS work because my level of committment is not high enough and that i
> won't be able to manage my bugs until 6 more months ?
>
> Sometimes i really don't understand you...
Because most pro-CDBS opinions here are from people dealing only with
"very standard" packaging cases and refuse to try to see things from
another POV. And don't accuse me of not understanding the issue or
similar crap. I created module-assistant includes for similar purposes a
while ago but I always cared about creating more benefits where they are
required without enchaining maintainers.
OTOH I am pissed, CDBS folks are using a var with conflicting name (and
module-assistant have been first with using it, I am not going to rename
the var), I sent my complaint to their ML and nothing happened. Now you
get a bug report.
And about "easy to extend"... I just looked trough the current manual
since someone told the docs have been improved. I still don't have a
single idea how can I easily put a certain custom tool call between
other debhelper commands.
> The documentation is still work in progress and is actively improved
> over time, just be patient *or* help.
Ehm, ok. But those docs are about internals, CDBS' developers should
know best how they work and be able to describe them best.
> > 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...
>
> In the past some mistakes were done in debhelper too, even if i don't
> recall a specific case to mention. That's not often this happen to CDBS,
> but i agree this should be avoided, that's why i'd like Peter to finaly
> accept co-maintainership.
Peter? Which Peter? Whoever, that is not about "mistakes happened there
to". With CDBS, a such bug IN CDBS means failure with working around it
becoming PITA.
> > 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.
>
> A documentation do exist, even if you seem to be completely blind and
> features which are described are behaviors you can count on. When a
Who is blind? Reread his text please. What about things you should
avoid, where are those documented?
> feature has changed for very important reasons like the control auto
> generation one, a warning is displayed (so you know you cannot count on
> it). Undocumented parts are either documentation lack or internal stuff
> you should not care about and count on. Nevertheless, i do agree this
Which simply indicated that if I care about such things or even need to
do, then CDBS sucks is nothing I would like to use. Not really
convincing when you require to throw away a nice working rules file and
replace with CDBS slave.
EOF,
Eduard.
Reply to: