On Fri, 14 Dec 2012, Gergely Nagy wrote: > > At the moment debian/compat allows to specify a single level, which > > debhelper > > takes as the compatibility level and enables(/disables?) some features > > accordingly. > > But often dh-based packaging itself is simple/generic enough to work fine > > even > > with previous releases of debhelper still "in production" in Debian stable > > or > > its derivatives (e.g. ubuntu 10.04 LTS carries 7.4.15ubuntu1). This > > hardcoded > > single compat leve unnecessarily complicates backporting requiring to > > patch debian/compat and debian/control for versioned build-depends on > > debhelper.
Thanks Gergely for the feedback! > Sorry, but this is a terrible idea. ;) > This introduces unrelability, as if > you'd build a 17-19 package on a system that is not up to date, and has > 18, you might get a different (and non-conforming) package, than if you > just build-depended on >= 19~. Hm... to me this doesn't sound like a solid argumentation/example of the stated terribleness: 1. it is a common practice to version Build-Depends on a minimal compatible version of the dependence, and I do not see why it should not be so 2. therefor getting "different" packages could happen anyways happen someone uses an outdated build environment and specifying the latest feature version for every dependent package would be overkill (so why debhelper should be special?) 3. but use of pbuilder/cowbuilder/... with an up-to-date environment is advised and our build farm is also kept relatively up-to-date naturally avoiding having non-conforming packages. (and if anything needs to be fixed, it would be binNMU away anyways upon necessary upgrade) The only use-case which my suggestion complicates ATM would be building in unstable+experimental where such strict versioning would be needed to force pulling-in debhelper from pinned-down experimental. But for such uploads (to experimental) strict versioning on debhelper to verify some new functionality would be sensible. Of cause, if debian/ packaging is done so that it relies on features introduced in debhelper 19 -- it must specify that as the minimal compatible version. On the other hand: I bet there should be some previous experience/bug report which would provide at least an example of why strict debhelper versioning was introduced in the first place. So -- a bit more solid argumentation would be appreciated > It is easier to backport a recent debhelper to Lucid, really. usually I prefer to avoid backporting core packages since that often might lead to truly terrible effects systemwide ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
