Re: dpkg backport in NEW
On 01/24/2012 07:10 PM, Gerfried Fuchs wrote:
> * Thomas Goirand <zigo@debian.org> [2012-01-23 07:20:46 CET]:
>> And it's also creating issues like someone can't check the version of
>> dpkg using packages.debian.org, then might depend on the wrong version
>> of dpkg.
>
> Uh? What has checking the version of dpkg on packages.d.o to do with
> depending on the wrong version of dpkg? If you depend on a specific
> version of dpkg you depend on that specific version of dpkg, I fail to
> see any connection what this has to do with the package version listed
> anywhere?
I wrote Depends:, but I meant Build-Depends:, sorry if this was
confusing. The goal was to declare that my rules file needed a more
recent version of dpkg with the "dpkg-buildflags --export=configure"
feature, which fails on Squeeze.
>> I have just uploaded MLMMJ with a depends dpkg-dev (>= 1.16.1.2~)
>> instead of 1.16.1.1~, because of this.
>
> If you put that version in there I would assume you to use a feature
> that was introduced in 1.16.1.2 instead of whatever version is in any
> part of the archive. If you do it because a specific version is in a
> specific release instead of a specific feature being in a specific
> version, there are troubles with your packages.
As said above: hardening build flags:
dpkg-buildflags --export=configure
I wanted to declare that, for an eventual backport of my package.
> Noone is expected to check any queue, people are expected to put
> versioned depends for specific feature requirements in the dependency,
> not because those versions are sitting in any part of the archive or any
> queue.
So, how do you keep track of each new feature? Could you take that
dpkg-buildflags as example, and tell me how I'm supposed to find out
when, in this long history of upload, the feature was added?
Am I suppose to read the changelog of dpkg, which is really HUGE, in the
hope that maybe, I'll find my way to guess whats the lowest version in
the history? Or should I read all Git commits? How can I make sure that,
even if the feature is there, there's no issue with it, fixed later? Or
is there any better trick? Or even better: what would be the point in
build-depending on a version that will *never* be in Debian anymore?
If your proposal is to effectively read the changelogs, then I don't
agree with such a loss of time with no valid advantage.
Thomas
P.S: I don't think this is very interesting. My package has been
corrected in SID (and in fact, it never had, in SID, the wrong
dependency that I talked about, -4 release had no build-depends at all
on dpkg) and a backport is now possible. Can we move on?
Reply to: