Re: Secret changes for binNMUs

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Nathanael Nerode-2
Blaaaargh!

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.

Now it's apparently been changed under our noses, in such a way that my
proposed
scheme won't work -- and furthermore anyone who implemented their own
version
of such code, in their own package, will find it magically broken.

Thanks to Goswin and Henrique for *notifying* people of this, since
apparently whoever changed it didn't think about the impacts on other
developers.

>  Instead binNMU versions are now made by adding +b1 (+b2, +b3) to the
>  version and containing a "Source: foo (non-NMU version)" line. The
>  later makes it possible to reliable associate binNMUs with their
>  source.

So how do we write a package Depends: line now?  Apparently the buildd uses
the original source,
and adds a changelog entry -- *but what happens to the {SourceVersion}
substitution?*  Does the buildd
alter the substvars file before compiling?  Does the {SourceVersion}
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?



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Henrique de Moraes Holschuh
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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Andreas Metzler
Henrique de Moraes Holschuh <[hidden email]> wrote:
[...]
> Meanwhile, I am using this: unversioned depends and two conflicts: (<<
> {Upstream-Version}), (>= {Upstream-Version}.1).

Depends: foo (>={Upstream-Version}), foo (<< {Upstream-Version}.1)

instead should also work without the need for a cumbersome <<conflict.
             cu andreas
PS: I've spent no thought whether {Upstream-Version}.1 is really
correct, it depends a lot on the versioning upstream chooses.
--
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Henrique de Moraes Holschuh
On Sat, 26 Nov 2005, Andreas Metzler wrote:
> Henrique de Moraes Holschuh <[hidden email]> wrote:
> [...]
> > Meanwhile, I am using this: unversioned depends and two conflicts: (<<
> > {Upstream-Version}), (>= {Upstream-Version}.1).
>
> Depends: foo (>={Upstream-Version}), foo (<< {Upstream-Version}.1)
>
> instead should also work without the need for a cumbersome <<conflict.

Yes. It is just a matter of which one you like better. You could also have
one depends and one conflicts instead of two conflicts or two depends.

--
  "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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Adeodato Simó-4
* Henrique de Moraes Holschuh [Sat, 26 Nov 2005 08:42:41 -0200]:

> Yes. It is just a matter of which one you like better. You could also have
> one depends and one conflicts instead of two conflicts or two depends.

  Versioned conflicts are said to increase apt's trouble to upgrade from
  one stable release to the next one. I have never heard the same
  comment applied to Depends: (<< V) relationshipts.

--
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Y sobre todo, tienes mucho de gilipollas.
                -- B.C.S. addressing P.G.i.Q in b8g


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Andreas Metzler
In reply to this post by Henrique de Moraes Holschuh
Henrique de Moraes Holschuh <[hidden email]> wrote:
> On Sat, 26 Nov 2005, Andreas Metzler wrote:
>> Henrique de Moraes Holschuh <[hidden email]> wrote:
>> [...]
>>> Meanwhile, I am using this: unversioned depends and two conflicts: (<<
>>> {Upstream-Version}), (>= {Upstream-Version}.1).

>> Depends: foo (>={Upstream-Version}), foo (<< {Upstream-Version}.1)

>> instead should also work without the need for a cumbersome <<conflict.

> Yes. It is just a matter of which one you like better.
[...]

Afaiui the different possibilties are not equivalent, because
conflicts need to be satisfied before installation, depends only at
configuration (after unpacking, ...).

Quoting policy:
| A Conflicts entry should almost never have an "earlier than" version
| clause.  This would prevent dpkg from upgrading or installing the
| package which declared such a conflict until the upgrade or removal of
| the conflicted-with package had been completed.
             cu andreas
--
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Simon Richter-2
In reply to this post by Henrique de Moraes Holschuh
Hi,

Henrique de Moraes Holschuh schrieb:

> We really need another substvar with different semantics.

http://lists.debian.org/debian-devel/2002/09/msg01251.html

   Simon

signature.asc (384 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Secret changes for binNMUs

Goswin von Brederlow
In reply to this post by Andreas Metzler
Andreas Metzler <[hidden email]> writes:

> Henrique de Moraes Holschuh <[hidden email]> wrote:
>> On Sat, 26 Nov 2005, Andreas Metzler wrote:
>>> Henrique de Moraes Holschuh <[hidden email]> wrote:
>>> [...]
>>>> Meanwhile, I am using this: unversioned depends and two conflicts: (<<
>>>> {Upstream-Version}), (>= {Upstream-Version}.1).
>
>>> Depends: foo (>={Upstream-Version}), foo (<< {Upstream-Version}.1)
>
>>> instead should also work without the need for a cumbersome <<conflict.
>
>> Yes. It is just a matter of which one you like better.
> [...]
>
> Afaiui the different possibilties are not equivalent, because
> conflicts need to be satisfied before installation, depends only at
> configuration (after unpacking, ...).
>
> Quoting policy:
> | A Conflicts entry should almost never have an "earlier than" version
> | clause.  This would prevent dpkg from upgrading or installing the
> | package which declared such a conflict until the upgrade or removal of
> | the conflicted-with package had been completed.
>              cu andreas

A conflicts is also not checked when other packages are upgraded
(downgraded). In practice that means that one can install the
conflicting old version when downgrading without also downgrading the
conflicting package. With depends dpkg fill error about it.

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]