Re: dpkg_1.16.1.1~bpo60+1_i386.changes REJECTED
Hi Gerfried,
On Wed, 02 Nov 2011, Gerfried Fuchs wrote:
> Dear Raphaël,
>
> unfortunately we will have to reject the dpkg upload. First of all, it
> fails for technical reasons because you didn't include the changelogs
> since the last upload to stable{,-backports} in the changes file.
> Please read the "Basic Rules" section in [1] again.
> [1] <http://backports-master.debian.org/Contribute/#index5h3>
Sorry about that. BTW is there a technical reason for this requirement?
Or is it just to make it easy to review the package?
> Secondly, given that dpkg is definitely one of the central packages I
> am puzzled that the upload wasn't discussed beforehand on the
> debian-backports mailinglist, at all. Such central packages have a
> quite deep impact on the user's systems and thus we would like to have a
> word on what is the need and requirement of the backport together with
> what potential issues and troubles it might cause and what is planed to
> do in such cases.
>
> Given that we had a fair amount of troubles with backports that did
> have quite some unexpected side-effects on other packages and
> difficulties to get those fixed properly, we want to have a clear view
> on what is planned to do in such cases, and thus the discussion is
> needed.
Well, I prepared this upload to make it easier to prepare other backports.
IOW it's not so much so that end-users can use dpkg 1.16.1.1 but so that
dpkg-dev 1.16.1.1 is available for other backports.
Given that debhelper depends on dpkg-dev >= 1.16.1 and that many packages
already start using debhelper compat level 9 in order to support hardening
build flags, I think it's important to have the latest dpkg-dev available.
This version also introduced Makefile snippets that will result in
build-dependencies against this version of dpkg.
I think that backports are built like experimental so that only packages
with an explicit build-dependency on the latest dpkg-dev would be built
with it (or an explicit dependency on the latest debhelper if that
backport also ends up depending on dpkg-dev 1.16.1). Thus I don't see any
harm in making it available.
I have not changed anything in the behaviour between the wheezy version
and the backports version. Doing so would only confuse people IMO.
This backport should thus not be used to build "normal" squeeze packages,
at it could introduce regressions (due to the build flags no longer being
set in the environment). And we cannot revert just this change because
it would break the packages using debian/compat=9 (see the recent
discussion on ubuntu-devel:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034351.html
and I would not like this kind of work-around in Debian).
Does this answer your question?
Let me know when/if I can proceed with the upload.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/
Reply to: