Re: Secret changes for binNMUs
On Fri, 25 Nov 2005, Nathanael Nerode wrote:
> OK. So I was working on the problem of fixing dpkg-dev so that
>
> foo Depends: foo-data {SourceVersion}, foo-libs {BinaryVersion}
>
> or something similar actually works. By parsing the version numbers.
I'd very much like debhelper or dpkg-* to give us another variable that
points to the parent version [changelog-wise] when bin NMUs are done, and to
the current version [changelog-wise] otherwise.
Meanwhile, I am using this: unversioned depends and two conflicts: (<<
{Upstream-Version}), (>= {Upstream-Version}.1).
BinNMUs won't break compatibility between arch any and arch all in any of my
packages, and debian revisions breaking them are rare enough that I will
track that by hand, so the above is enough (although far from ideal).
> So how do we write a package Depends: line now? Apparently the buildd uses
> the original source,
See above. We had that problem already, but now we will have to deploy a
real solution instead of hacks. Ain't that nice? :-)
Does anyone have any idea on how to detect if a currently running buind is a
bin NMU or not?
> and adds a changelog entry -- *but what happens to the {SourceVersion}
> substitution?* Does the buildd
> alter the substvars file before compiling? Does the {SourceVersion}
I bet it works in the simplest way possible, i.e. it is set to the latest
changelog entry: the binNMU version.
> substitution end up being the original 1.2-3 source version, or the
> 1.2-3+b4 version? Whichever it ends up being, *how do we get the other
> one* if we need it?
We really need another substvar with different semantics.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: