On 12-07-06 at 04:09pm, Dominique Dumont wrote: > On Friday 06 July 2012 15:30:23 Jonas Smedegaard wrote: > > On 12-07-06 at 10:35am, Dominique Dumont wrote: > > > > d) is harmful: a recent cdbs _is_ needed. In this particular > > > > case the CDBS snippet perl-makemaker.mk is included which was > > > > unavailable prior to cdbs 0.4.73. > > > > > > > > It could be argued that d) is not harmful because only unstable > > > > (and testing) is targeted - backporting is unsupported > > > > officially. In that case this particular versioned dependency > > > > is indeed unneded - but then so are versioned build-dependencies > > > > on debhelper even in compatibility level 8 and 9! > > > > > > I would not recommend to remove debhelper > 9 as this would harm > > > backport on squeeze. > > > > I don't understand above sentence. > > Well, when backporting, you have to consider whether a package is > compatible or not with with your target. If you consider backporting a > pacakge with debhelper > 9 for squeeze, you know that you will have > some rework to do. > > If the required dep is removed, people doing backports for squeeze > will have more err, unwelcome surprises. These are the debhelper versions in the officially released suites: Lenny: 7.0.15 Squeeze: 8.0.0. If you are not taking backports.debian.org into account, I suspect you really mean debhelper > 8. > > Please mention backports.debian.org explicitly if you are talking > > about backporting to there specifically. I don't. > > Neither do I. sorry. The main question when cleaning dependencies is > where to draw the line. IIRC, the consensus was to remove version req > that can be satisfied on oldstable. (which is admitedly a blurry > notion since wheezy froze). Not at all blurry to me: It makes sense to support backporting to officially maintained releases of Debian, when reasonable. Freeze does not affect this - cancellation of security support for oldstable does. Versioned package relations satisfied in all officially maintained Debian releases can safely be simplified to unversioned relations. This is the reason I drop versioning when using debhelper compat level 7 (and I do not depend on any specific features introduced later than the major release of the tool). When Lenny is no longer officially supported by Debian, I will use debhelper compatibility level 8 by default. (and no, multiarch support does *not* require debhelper 9!) I require recent CDBS more frequently than I require recent debhelper. Reason for that is that CDBS itself is is easy backportable to oldstable, unlike debhelper. > > > Note that, by default cme will not remove versioned dependencies > > > required for oldstable, provided the information is provided by > > > madison. > > > > I don't understand what you mean here. How can madison know if what > > features of CDBS (or debhelper or whatever) used speficially in a > > certain package. causing a versioned dependency? > > That's not the point. madison is used to know whether the versioned > dependency can be satisfied in all supported cases (usually taking > into account oldstable). If yes, the versioned req is removed. I complained about two things regarding versioned dependencies: * unneeded debhelper versioning was added * needed cdbs versioning was dropped Your comment above is about Config::Model relying on Madison for _removal_ of versioning, right? Is your comment above somehow related to my complaint about dropping needed cdbs versioning? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature