uploaded first pkg: pd-motex

Sat Aug 14 14:43:27 UTC 2010

On Sat, Aug 14, 2010 at 12:13:52PM +0200, Reinhard Tartler wrote:
>On Fri, Aug 13, 2010 at 21:15:26 (CEST), Jonas Smedegaard wrote:
>> On Fri, Aug 13, 2010 at 05:20:45PM +0200, Reinhard Tartler wrote:
>>>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!
>
>These two sentences doesn't make sense to me together. Either you or I 
>have misunderstood backports.org. That repo does not build by default 
>against packages also in backports.org, unless explicitly requested by 
>the build-depends, exactly like experimental is currently handled.

Official Debian packages are compiled in a Debian unstable environment.

A "backport" to me is the task of recompiling package(s) in an older 
Pure Debian environment, either officially released or a snapshot of a 
staging area.  Examples of backporting targets are "Debian/Lenny", 
"Debian Etch" and "Debian testing as of noon 2010-08-14".

Recompiling packages for something else than an older Debian environment 
is "sideporting" to me.  Examples of sideports are "Ubuntu Jaunty", 
"Skolelinux Etch" and "the mixture of Debian Lenny + Lenny branch of 
backports.org as of noon 2010-08-14".

Packages not requiring things recently introduced into Debian I call 
"backports-friendly".  The further back the requirements are satisfied, 
the more backports-friendly that particular package is.

It seems that your use of the term "bacporting" is what I would describe 
as "sideporting to the mixture of Debian stable + a few packages 
cherry-picked from stable branch of backports.org as of now".

With your use of the term (if I got it correctly) we might reach a 
different conclusion regarding which packages are backport-friendly, 
depending on which dependencies happens to be offered that particular 
day at backports.org.  Right?

>> And yes, CDBS is *genuinely* backportable more than short-form dh!
>
>if your copy of cdbs is recent enough, sure. but the same argument
>counts for dh7 as well, which has a 7.0.15 in stable. The only thing
>that doesn't work in stable by itself is the quilt series trick.

If the cdbs package in the target build environment do not satisfy 
requirements of the package being built, then that package is less 
backport-friendly as either the packaging needs some hacking or a newer 
cdbs needs to be backported (by yourself or someone else via e.g. 
backports.org). However done the target environment becomes slightly 
"contaminated" thus slightly less reliable.

jackd2 and bitmeter use CDBS and are backport-friendly: They compile in 
plain Lenny without contaminating it with any other bacported packages, 
neither locally built nor e.g. backports.org.

calf use CDBS and is less backport-friendly: it requires a recent cdbs. 

ffmpeg use short-form dh and is backport-friendly: it uses only features 
also available in stable.

Bitmeter is *more* backport-friendly than ffmpeg because its 
build-dependencies are (mostly if not fully) satisfied even in 
oldstable.

You may judge oldstable as obsolete for your purposes. So do I these 
days, but I did not 6 months ago, and I most likely will not render 
Lenny obsolete as soon as it enters oldstable but only some time after 
that.  The very aim (for me, at least) of backport-friendliness is to 
ease use in unusual environments.

>>    1) Demonstrating "a case" does not undermine "more backportable".
>
>sure, but already this thread gives me enough reason to not even try 
>this further.

So you do not disagree that CDBS is "more backportable" but dislike it 
for other reasons.  Fair enough: Benjamin asked about reasons for using 
CDBS over short-form dh - not reasons to avoid it.

>>    2) Releasing testing packages as stable is flawed: Ubuntu is 
>>       flawed!
>
>because they want to build packages that require newer CDBS? come on, 
>they just take what's available in unstable. OK, they switched now to 
>testing, IIRC, but now we're really offtopic.

No, because that particular CDBS release was broken.  Earlier versions 
worked, and later versions worked.

The case you referred to concerned a FTBFS on Ubuntu due to a broken 
release of CDBS on that system.  Same things occur in Debian if not 
properly tracking the branch used.  This is not tied to CDBS at all.

I can elaborate more if you do not understand my point.

Ubuntu bashing is off-topic, agreed.

>> 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.
>
>"more cases"? Sorry, this does not match my experiences with cdbs so 
>far.

I find that a pretty weak argument, especially taiored with my knowledge 
of you as packaging for Ubuntu (as well as Debian) and your only example 
provided was due to Ubuntu shipping a cdbs release considered broken in 
Debian.

>debhelper maintains a history of very stable interfaces, called compat 
>levels. I'd really love to see something similar to cdbs. And this very
strict commitment to stable interfaces and semantics help 
>a lot for backporting packages.

Clearly defining when packaging what new funky features is used helps 
*hacking* efforts of less backport-friendly packages.

What helps even more, however, is that hacking is not needed.  Clear ABI 
versioning does not help here, but sticking to backwards-compatible 
parts of an ABI does.

For debhelper the main problem for backportability have recently 
been the very use of short-form dh.  This is arguably historic, as 
stable contains the initial basic implementation of this new feature.  
Currently - for backports to Debian stable - the problem then is the use 
of extensions to short-form dh which requires e.g. debhelper 7.2.

Congratulations: You made me discuss debhelper. I tried to avoid it, but 
there you go: let the flames flow.

>> 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...
>
>as already pointed, hardly anyone cares about oldstable (or earlier) 
>anymore. What I care much more would be to backport to previous ubuntu 
>releases, particularily those that ship "broken" releases of cdbs.
>
>needless to say that dh packages make much fewer problems there...

I wholeheartedly agree with you that debhelper-only packaging is not 
affected by systems shipping with a broken release of cdbs.

Halleluja!

>moreover, scanning for new upstream releases or checking for license 
>problems is hardy a practical concern when backporting packages. 
>Therefore, I think that shouldn't be in debian/rules, instead it should 
>focus on building packages.

CDBS being more backport-friendly is *one* argument out of several.  
Yes, I agree with you that not all features of CDBS are relevant when 
backporting.  I do claim that all of them are relevant for packaging!

>>>> 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).
>
>You claimed that "short-form dh somewhat reinvents make in Perl", which 
>I don't follow.
>
>My argument is that debian/rules is a build script. The feature that 
>makes make unique is its dependency resolution feature, and this is 
>often not that essential for building software packages. For this 
>reason, I really disagree with the "reinventing" part of your claim.

I disagree that the only benefit of Make is its dependency resolution.

>>> 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.
>
>Might be stronger in ubuntu than in debian, I didn't check that myself, 
>though.

You could try provide some examples...

I suspect that you confuse "using cdbs" with "including a shared make 
snippet into the rules file".

   - Jonas

-- 
   * Jonas Smedegaard - idealist & Internet-arkitekt
   * Tlf.: +45 40843136  Website: http://dr.jones.dk/

   [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100814/34e5cc26/attachment-0001.pgp>