Re: dpkg_1.16.1.1~bpo60+1_i386.changes REJECTED
On Wed, 2 Nov 2011, intrigeri wrote:
> this version of dpkg not being available in the backports repository
> is the only reason that blocks me from replacing hardening-wrapper
> with the new dpkg -based hardening build flags in packages I maintain.
You can still use it. In fact, the mksh package (which, admittedly,
does things _quite_ different from most packages due to having a
fallback mechanism to eglibc if dietlibc (or klibc, but that’s not
used in the archive yet) fail) uses dpkg-buildflags, with a fallback
on the old method.
On Thu, 3 Nov 2011, Gerfried Fuchs wrote:
> Most packages these days are done within some VCSes. Having a seperate
> branch in there for the backports seems only natural. Being able to
> cherry-pick the commit for such new features and unroll those specific
> changes in said backports branch doesn't sound like magic to me.
Yes. Packages can still be backported, just not that easily. Or they
need to wait a release cycle (or a cycle plus a year) before picking
up new features. Choose yours.
That being said, I’m sort of glad that newer debhelper has been back‐
ported to lenny (although I think I’ve seen behavioural differences
where the feature set was not fully adjusted for lenny), but with
these core tools (dpkg even more so), I’d indeed be careful.
bye,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
Reply to: