uploaded first pkg: pd-motex

[Andres Mejia]

On Friday 13 August 2010 15:15:26 Jonas Smedegaard wrote:
> On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:
> >Aah, finally a new round of cdbs vs. dh bashing, we didn't have enough
> >of that at debconf 10 ;-)
> 
> The best way to keep a thread alive(!) is to feed it new arguments, as
> you do below.
> 
> I honestly tried to not do side-by-side comparison between dh7 and CDBS,
> but stick to facts about CDBS itself.
> 
> I shall try my best to keep at that, and leave it to others throwing
> questions or counter-arguments to decide if this thread should be kept
> alive or not.
> 
> >On Fri, Aug 13, 2010 at 10:40:08 (CEST), Jonas Smedegaard wrote:
> >> CDBS is more backports-friendly (beyond backports.org too!).
> >
> >It is only more backports-friendly if you also always backport the very
> >latest version of cdbs, which does not match my definition of
> >'backport' at all.
> 
> You are completely right that ideal backportability means no dependency
> on other backports.  Which is the reason I counted backports.org out!
> 
> And yes, CDBS is *genuinely* backportable more than short-form dh!
> 
> >cdbs itself does not seem to be available on backports.org at all.
> 
> I dislike[1] backports.org so do not contribute to that myself.
> 
> Others apperently don't either - most likely due to it not being
> important: See above!
> 
> >Moreover, These are the used versions in ubuntu:
> >      cdbs | 0.4.51ubuntu1 |         hardy | source, all
> >      cdbs | 0.4.52ubuntu18 |        jaunty | source, all
> >      cdbs | 0.4.59ubuntu4 |        karmic | source, all
> >      cdbs | 0.4.62+nmu1ubuntu9 |         lucid | source, all
> >      cdbs | 0.4.83ubuntu1 |      maverick | source, all
> >
> >And I've already shown you a case where a package failed to build with
> >lucid's cdbs and you just told me that ubuntu where shipping broken
> >cdbs package. Sorry, that does not help me at all with backporting
> >packages.
> 
>     1) Demonstrating "a case" does not undermine "more backportable".
> 
>     2) Releasing testing packages as stable is flawed: Ubuntu is flawed!
> 
> With "more backportable" I mean to say that CDBS in more cases than
> short-form dh is it possible to compile packages in an older Debian
> environment either a) as-is or b) with minor adjustments - e.g. changing
> or removing build-dependencies.
> 
> Oh, and if you are lazy (or don't want to touch those weird CDBS-using
> debian/control files) then CDBS itself is backportable as its
> dependencies is fulfilled even on Etch (and, if I recall correctly,
> Sarge too!).  Backporting a recent debhelper requires backporting dpkg
> which I wouldn't dare do...

I would like to chime in and say that with the packages I've worked on 
(besides my own), I found that both dh and cdbs get whatever I need done. I 
however prefer dh. Really the only reason I've stuck with dh over cdbs in my 
packages is because cdbs depends on debhelper. cdbs even build depends on 
debhelper. I've asked myself, "what's the point of having 2 build dependencies 
when 1 is all that I need". Because of this, I found that I may as well use 
debhelper directly for packaging, as opposed to using debhelper indirectly via 
cdbs.

I'm not sure if I'm alone in this kind of reasoning. However, if you can 
somehow remove cdbs dependency on debhelper, I'm sure cdbs would be much more 
interesting.

Now if it's already possible to use cdbs without debhelper, than I'll go ahead 
and admit that I did not know. So far however, I haven't found how to use cdbs 
without debhelper in cdbs documentation or in cdbs examples. Also, cdbs 
dependency and build dependency on debhelper leads me to believe that it's not 
currently possible.

> If all of that "does not help [you] at all" then too bad: I dare say
> that any narrower definition of "more backportable" won't get you very
> far with most backporting efforts.
> 
> >> CDBS provides routines to fetch and repackage upstream tarballs
> >> 
> >> CDBS provides routines to track copyright and licensing info of
> >> sources.
> >
> >What is the technical reasoning for needing to integrate these logics
> >into debian/rules? I think as developer I'm much more flexible if they
> >
> >are implemented in seperate, reusable stand-alone tools. This way:
> > a) more packages would use the same code to do these tasks
> > b) these helper tools could be maintained and backported independently
> > 
> >    of cdbs
> > 
> > c) they have really nothing to do with the act of building packages,
> > 
> >    but are more general maintenance tasks
> 
> Yes, and this is a noble goal for the future.  As I already told you at
> debconf I plan to do that for the copyright & licensing part.
> 
> >I think this is the thing that makes me dislike cdbs, too many
> >maintenance tasks are integrated into debian/rules and therefore, are
> >implemented in make, which is a fine language that I also like to
> >program with, but for these tasks, 'make' doesn't really help much.
> 
> I totally agree with you that make is not ideal for all of this.
> 
> This is the reason copyright & licensing code is implemented in Perl.
> 
> Make is powerful to resolve chains of smaller rules and
> interdependencies betwen them, which is quite useful for other parts
> like the get-orig-source target[2].  When uscan perhaps matures to
> contain more of these routines then newer releases of CDBS can embrace
> that - while stil being backports-frindly :-)
> 
> >Jonas, would it be an option to you to implement them in a language
> >other than make? Ideally, we could try (again) to push at least some of
> >these tasks into the devscripts package, which is more the place I think
> >they belong to.
> 
> As mentioned above (and partly told to you in person already at Debconf)
> this is slowly happening already.
> 
> And really I feel that this is sliding far quite away from the original
> question: "Are there any technical reasons for not using dh [but stick
> with CDBS]?" as asked by Benjamin[3].
> 
> >> CDBS is less invasive - e.g. can be used with manually run dh_* commands
> >
> >as indicated above, the integration of all kinds of maintenance tasks
> >fits my understanding of "more invasive", because more unrelated tasks
> >are implemented into a single program: debian/rules.
> 
> Ok, so you interpret the term "invasive" differently than me. I believe
> I did later elaborate on the intended meaning of above phrase, and if
> this is more than a word game, then aim at that: please shoot the
> messenger, not the message ;-)
> 
> >> CDBS is written in make (short-form dh somewhat reinvents make in
> >> Perl)
> >
> >it reinvents much logic that cdbs chooses to implement in make, but
> >also most of cdbs, espc. the tasks that you indicated above, don't
> >really benefit from the properties of the make language.
> 
> I fail to see how your argument here is different from your argument
> further up (which I disagree with).
> 
> I do feel that my argument is different is different from my other
> original arguments.  I can clarify this if anyone wants, but hesitate to
> not risk repeating myself or spawning too much new threads...
> 
> >And now for context of everyone that has not attended Jonas and my real
> >life flamefest at debconf 10, yes, Jonas and I had (at least one?) long
> >real-life conversation about cdbs. It's not that I really disklike it
> >or something, au contraire, I do think that cdbs does have benefit for
> >some groups of packages. E.g. I know that the gnome and kde package
> >consolidate a lot of build logic into cdbs, and this really makes sense
> >to me.
> 
> I am unaware of CDBS being aggressively used by the GNOME or KDE teams,
> or any other teams in particular for that matter.
> 
> 
> Phew - hope I did not stir up too many new seeds for further discussion.
> 
> 
> Regards,
> 
>   - Jonas
> 
> 
> [1] I may change my mind regarding backports.org now that I (at a
> debian-mm BoF last week) learned how it might be more sanely constructed
> than I had (wrongly or through earlier design) had understood.
> 
> [2] At the get-orig-source target I actually cheat at the moment and
> embed a shell script instead of more structured make usage.
> 
> [3] The trailing part of that pseudo-quote is my fabrication, but
> Benjamin clarified that he favored CDBS over the older long-form dh_*.

-- 
Regards,
Andres Mejia