Breaks & Replaces in debian/control in backports

Breaks & Replaces in debian/control in backports

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

Hi Ken,

In the context of https://github.com/ceph/ceph/pull/5206 we need to adapt the version constraints for the Breaks / Replaces in debian/control. What we currently do is something like x.y.z-vvv where we randomly pick vvv to be something we're sure won't be greater than the actual vvv from git-describe that will be associated to this specific commit (otherwise the constraints won't be satisfied and the install will break). 

When backporting it translates into something like:

Package: ceph
Depends: ceph-common (>= 0.94.2-23)

Package: ceph-common
Replaces: ceph-client-tools,
	  ceph (<< 0.94.2-23),
Breaks: ceph (<< 0.94.2-23),

I propose instead we use the version of the previous stable release like so:

Package: ceph
Depends: ceph-common (>> 0.94.2)

Package: ceph-common
Replaces: ceph-client-tools,
	  ceph (<= 0.94.2),
Breaks: ceph (<= 0.94.2),

I think it achieves the same thing and is less error prone in the case of backports. The risk is that upgrading from v0.94.2-34 to the version with this change will fail because the conditions are satisified (it thinks all versions after v0.94.2 have the change). But the odds of having a test machine with this specific version already installed are close to non-existent. The odds of us picking the wrong number and ending up with something that's either too high or too small are higher.

What do you think ?

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Breaks & Replaces in debian/control in backports

[Ken Dreyer]

On 07/19/2015 05:28 AM, Loic Dachary wrote:

> I think it achieves the same thing and is less error prone in the case of backports. The risk is that upgrading from v0.94.2-34 to the version with this change will fail because the conditions are satisified (it thinks all versions after v0.94.2 have the change). But the odds of having a test machine with this specific version already installed are close to non-existent. The odds of us picking the wrong number and ending up with something that's either too high or too small are higher.
> 
> What do you think ?
> 

I think this is great, thanks for proposing it. We should also write our
convention down someplace (SubmittingPatches, or the wiki, or something)

- Ken

Re: Breaks & Replaces in debian/control in backports

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]

Hi,

What I proposed does not actually work because the package versions are not ceph-0.94.2 but ceph-0.94.2-1trusty ( https://github.com/ceph/ceph-build/blob/master/gen_debian_version.sh and https://github.com/ceph/ceph-build/blob/master/build_debs.sh#L35) and will therefore match the constraint and upgrading from ceph-0.94.2-1trusty to ceph=0.94.2-197-g1e841b0-1trusty or ceph=0.94.3-1trusty will not do the right thing:

2015-07-29T22:06:05.579 INFO:teuthology.orchestra.run.ovh228114:Running: u'sudo DEBIAN_FRONTEND=noninteractive apt-get -y --force-yes -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install librbd1-dbg=0.94.2-197-g1e841b0-1trusty ceph=0.94.2-197-g1e841b0-1trusty ceph-test=0.94.2-197-g1e841b0-1trusty ceph-dbg=0.94.2-197-g1e841b0-1trusty rbd-fuse=0.94.2-197-g1e841b0-1trusty librados2-dbg=0.94.2-197-g1e841b0-1trusty ceph-fuse-dbg=0.94.2-197-g1e841b0-1trusty libcephfs-jni=0.94.2-197-g1e841b0-1trusty libcephfs1-dbg=0.94.2-197-g1e841b0-1trusty radosgw=0.94.2-197-g1e841b0-1trusty librados2=0.94.2-197-g1e841b0-1trusty libcephfs1=0.94.2-197-g1e841b0-1trusty ceph-mds=0.94.2-197-g1e841b0-1trusty radosgw-dbg=0.94.2-197-g1e841b0-1trusty librbd1=0.94.2-197-g1e841b0-1trusty python-ceph=0.94.2-197-g1e841b0-1trusty ceph-test-dbg=0.94.2-197-g1e841b0-1trusty ceph-fuse=0.94.2-197-g1e841b0-1trusty ceph-common=0.94.2-197-g1e841b0-1trusty libcephfs-java=0.94.2-197-g1e841b0-1trusty 
ceph-common-dbg=0.94.2-197-g1e841b0-1trusty ceph-mds-dbg=0.94.2-197-g1e841b0-1trusty'

2015-07-29T22:11:11.258 INFO:teuthology.orchestra.run.ovh228114.stderr:dpkg: error processing archive /var/cache/apt/archives/ceph-common_0.94.2-197-g1e841b0-1trusty_amd64.deb (--unpack):
2015-07-29T22:11:11.259 INFO:teuthology.orchestra.run.ovh228114.stderr: trying to overwrite '/usr/lib/python2.7/dist-packages/ceph_argparse.py', which is also in package ceph 0.94.2-1trusty

The release files found in ceph.com have a fixed prefix ( -1trusty, -1jessie, etc. ) if the version in Breaks and Replaces is -2 it will always be immediately greater. This is not what happens in Debian GNU/Linux or Ubuntu because the package is not part of the sources. When packaging for ceph.com repositories we are creating packages that are native (in the sense that modifying the package requires a new release of the sources because the packaging is part of the sources) but contrary to what is usually done with native packages, we append a -XXXX debian version which is supposed to be the version of the debian directory when it lives outside of the sources.

I filed http://tracker.ceph.com/issues/12529 as "Fix" : it's not a bug but would definitely make things easier to understand.

Please let me know if I got it right this time ;-)

Cheers

On 19/07/2015 13:28, Loic Dachary wrote:
> Hi Ken,
> 
> In the context of https://github.com/ceph/ceph/pull/5206 we need to adapt the version constraints for the Breaks / Replaces in debian/control. What we currently do is something like x.y.z-vvv where we randomly pick vvv to be something we're sure won't be greater than the actual vvv from git-describe that will be associated to this specific commit (otherwise the constraints won't be satisfied and the install will break). 
> 
> When backporting it translates into something like:
> 
> Package: ceph
> Depends: ceph-common (>= 0.94.2-23)
> 
> Package: ceph-common
> Replaces: ceph-client-tools,
> 	  ceph (<< 0.94.2-23),
> Breaks: ceph (<< 0.94.2-23),
> 
> I propose instead we use the version of the previous stable release like so:
> 
> Package: ceph
> Depends: ceph-common (>> 0.94.2)
> 
> Package: ceph-common
> Replaces: ceph-client-tools,
> 	  ceph (<= 0.94.2),
> Breaks: ceph (<= 0.94.2),
> 
> I think it achieves the same thing and is less error prone in the case of backports. The risk is that upgrading from v0.94.2-34 to the version with this change will fail because the conditions are satisified (it thinks all versions after v0.94.2 have the change). But the odds of having a test machine with this specific version already installed are close to non-existent. The odds of us picking the wrong number and ending up with something that's either too high or too small are higher.
> 
> What do you think ?
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Breaks & Replaces in debian/control in backports

[Sage Weil]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4664 bytes --]

On Thu, 30 Jul 2015, Loic Dachary wrote:
> Hi,
> 
> What I proposed does not actually work because the package versions are not ceph-0.94.2 but ceph-0.94.2-1trusty ( https://github.com/ceph/ceph-build/blob/master/gen_debian_version.sh and https://github.com/ceph/ceph-build/blob/master/build_debs.sh#L35) and will therefore match the constraint and upgrading from ceph-0.94.2-1trusty to ceph=0.94.2-197-g1e841b0-1trusty or ceph=0.94.3-1trusty will not do the right thing:
> 
> 2015-07-29T22:06:05.579 INFO:teuthology.orchestra.run.ovh228114:Running: u'sudo DEBIAN_FRONTEND=noninteractive apt-get -y --force-yes -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install librbd1-dbg=0.94.2-197-g1e841b0-1trusty ceph=0.94.2-197-g1e841b0-1trusty ceph-test=0.94.2-197-g1e841b0-1trusty ceph-dbg=0.94.2-197-g1e841b0-1trusty rbd-fuse=0.94.2-197-g1e841b0-1trusty librados2-dbg=0.94.2-197-g1e841b0-1trusty ceph-fuse-dbg=0.94.2-197-g1e841b0-1trusty libcephfs-jni=0.94.2-197-g1e841b0-1trusty libcephfs1-dbg=0.94.2-197-g1e841b0-1trusty radosgw=0.94.2-197-g1e841b0-1trusty librados2=0.94.2-197-g1e841b0-1trusty libcephfs1=0.94.2-197-g1e841b0-1trusty ceph-mds=0.94.2-197-g1e841b0-1trusty radosgw-dbg=0.94.2-197-g1e841b0-1trusty librbd1=0.94.2-197-g1e841b0-1trusty py
 thon-ceph=0.94.2-197-g1e841b0-1trusty ceph-test-dbg=0.94.2-197-g1e841b0-1trusty ceph-fuse=0.94.2-197-g1e841b0-1trusty ceph-common=0.94.2-197-g1e841b0-1trusty libcephfs-java=0.94.2-197-g1e84!
 1b0-1trusty 
> ceph-common-dbg=0.94.2-197-g1e841b0-1trusty ceph-mds-dbg=0.94.2-197-g1e841b0-1trusty'
> 
> 2015-07-29T22:11:11.258 INFO:teuthology.orchestra.run.ovh228114.stderr:dpkg: error processing archive /var/cache/apt/archives/ceph-common_0.94.2-197-g1e841b0-1trusty_amd64.deb (--unpack):
> 2015-07-29T22:11:11.259 INFO:teuthology.orchestra.run.ovh228114.stderr: trying to overwrite '/usr/lib/python2.7/dist-packages/ceph_argparse.py', which is also in package ceph 0.94.2-1trusty
> 
> The release files found in ceph.com have a fixed prefix ( -1trusty, -1jessie, etc. ) if the version in Breaks and Replaces is -2 it will always be immediately greater. This is not what happens in Debian GNU/Linux or Ubuntu because the package is not part of the sources. When packaging for ceph.com repositories we are creating packages that are native (in the sense that modifying the package requires a new release of the sources because the packaging is part of the sources) but contrary to what is usually done with native packages, we append a -XXXX debian version which is supposed to be the version of the debian directory when it lives outside of the sources.
> 
> I filed http://tracker.ceph.com/issues/12529 as "Fix" : it's not a bug but would definitely make things easier to understand.
> 
> Please let me know if I got it right this time ;-)

Should we just drop the suffix?  I tried to match up with the backport 
suffixes (e.g., ~bpo70 for wheezy) so that when you did a dist-upgrade it 
would be able to pull in the next version.  It sounds like it's not 
worth it, though...

sage


> 
> Cheers
> 
> On 19/07/2015 13:28, Loic Dachary wrote:
> > Hi Ken,
> > 
> > In the context of https://github.com/ceph/ceph/pull/5206 we need to adapt the version constraints for the Breaks / Replaces in debian/control. What we currently do is something like x.y.z-vvv where we randomly pick vvv to be something we're sure won't be greater than the actual vvv from git-describe that will be associated to this specific commit (otherwise the constraints won't be satisfied and the install will break). 
> > 
> > When backporting it translates into something like:
> > 
> > Package: ceph
> > Depends: ceph-common (>= 0.94.2-23)
> > 
> > Package: ceph-common
> > Replaces: ceph-client-tools,
> > 	  ceph (<< 0.94.2-23),
> > Breaks: ceph (<< 0.94.2-23),
> > 
> > I propose instead we use the version of the previous stable release like so:
> > 
> > Package: ceph
> > Depends: ceph-common (>> 0.94.2)
> > 
> > Package: ceph-common
> > Replaces: ceph-client-tools,
> > 	  ceph (<= 0.94.2),
> > Breaks: ceph (<= 0.94.2),
> > 
> > I think it achieves the same thing and is less error prone in the case of backports. The risk is that upgrading from v0.94.2-34 to the version with this change will fail because the conditions are satisified (it thinks all versions after v0.94.2 have the change). But the odds of having a test machine with this specific version already installed are close to non-existent. The odds of us picking the wrong number and ending up with something that's either too high or too small are higher.
> > 
> > What do you think ?
> > 
> 
> -- 
> Loïc Dachary, Artisan Logiciel Libre
> 
> 

Re: Breaks & Replaces in debian/control in backports

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 5181 bytes --]

Hi Sage :-)

On 30/07/2015 14:25, Sage Weil wrote:
> On Thu, 30 Jul 2015, Loic Dachary wrote:
>> Hi,
>>
>> What I proposed does not actually work because the package versions are not ceph-0.94.2 but ceph-0.94.2-1trusty ( https://github.com/ceph/ceph-build/blob/master/gen_debian_version.sh and https://github.com/ceph/ceph-build/blob/master/build_debs.sh#L35) and will therefore match the constraint and upgrading from ceph-0.94.2-1trusty to ceph=0.94.2-197-g1e841b0-1trusty or ceph=0.94.3-1trusty will not do the right thing:
>>
>> 2015-07-29T22:06:05.579 INFO:teuthology.orchestra.run.ovh228114:Running: u'sudo DEBIAN_FRONTEND=noninteractive apt-get -y --force-yes -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install librbd1-dbg=0.94.2-197-g1e841b0-1trusty ceph=0.94.2-197-g1e841b0-1trusty ceph-test=0.94.2-197-g1e841b0-1trusty ceph-dbg=0.94.2-197-g1e841b0-1trusty rbd-fuse=0.94.2-197-g1e841b0-1trusty librados2-dbg=0.94.2-197-g1e841b0-1trusty ceph-fuse-dbg=0.94.2-197-g1e841b0-1trusty libcephfs-jni=0.94.2-197-g1e841b0-1trusty libcephfs1-dbg=0.94.2-197-g1e841b0-1trusty radosgw=0.94.2-197-g1e841b0-1trusty librados2=0.94.2-197-g1e841b0-1trusty libcephfs1=0.94.2-197-g1e841b0-1trusty ceph-mds=0.94.2-197-g1e841b0-1trusty radosgw-dbg=0.94.2-197-g1e841b0-1trusty librbd1=0.94.2-197-g1e841b0-1trusty python-ceph=0.94.2-197-g1e841b0-1trusty ceph-test-dbg=0.94.2-197-g1e841b0-1trusty ceph-fuse=0.94.2-197-g1e841b0-1trusty ceph-common=0.94.2-197-g1e841b0-1trusty libcephfs-java=0.94.2-197-g1e84!
>  1b0-1trusty 
>> ceph-common-dbg=0.94.2-197-g1e841b0-1trusty ceph-mds-dbg=0.94.2-197-g1e841b0-1trusty'
>>
>> 2015-07-29T22:11:11.258 INFO:teuthology.orchestra.run.ovh228114.stderr:dpkg: error processing archive /var/cache/apt/archives/ceph-common_0.94.2-197-g1e841b0-1trusty_amd64.deb (--unpack):
>> 2015-07-29T22:11:11.259 INFO:teuthology.orchestra.run.ovh228114.stderr: trying to overwrite '/usr/lib/python2.7/dist-packages/ceph_argparse.py', which is also in package ceph 0.94.2-1trusty
>>
>> The release files found in ceph.com have a fixed prefix ( -1trusty, -1jessie, etc. ) if the version in Breaks and Replaces is -2 it will always be immediately greater. This is not what happens in Debian GNU/Linux or Ubuntu because the package is not part of the sources. When packaging for ceph.com repositories we are creating packages that are native (in the sense that modifying the package requires a new release of the sources because the packaging is part of the sources) but contrary to what is usually done with native packages, we append a -XXXX debian version which is supposed to be the version of the debian directory when it lives outside of the sources.
>>
>> I filed http://tracker.ceph.com/issues/12529 as "Fix" : it's not a bug but would definitely make things easier to understand.
>>
>> Please let me know if I got it right this time ;-)
> 
> Should we just drop the suffix?  I tried to match up with the backport 
> suffixes (e.g., ~bpo70 for wheezy) so that when you did a dist-upgrade it 
> would be able to pull in the next version.  It sounds like it's not 
> worth it, though...

The suffix should indeed be dropped entirely: native packages do not have a suffix (i.e. debian version) because the debian directory is in the source tree. Given the number of scripts that depend on this, I suppose dropping the suffix would require a lot of testing to make sure it does not break something somewhere.

Cheers
> 
> sage
> 
> 
>>
>> Cheers
>>
>> On 19/07/2015 13:28, Loic Dachary wrote:
>>> Hi Ken,
>>>
>>> In the context of https://github.com/ceph/ceph/pull/5206 we need to adapt the version constraints for the Breaks / Replaces in debian/control. What we currently do is something like x.y.z-vvv where we randomly pick vvv to be something we're sure won't be greater than the actual vvv from git-describe that will be associated to this specific commit (otherwise the constraints won't be satisfied and the install will break). 
>>>
>>> When backporting it translates into something like:
>>>
>>> Package: ceph
>>> Depends: ceph-common (>= 0.94.2-23)
>>>
>>> Package: ceph-common
>>> Replaces: ceph-client-tools,
>>> 	  ceph (<< 0.94.2-23),
>>> Breaks: ceph (<< 0.94.2-23),
>>>
>>> I propose instead we use the version of the previous stable release like so:
>>>
>>> Package: ceph
>>> Depends: ceph-common (>> 0.94.2)
>>>
>>> Package: ceph-common
>>> Replaces: ceph-client-tools,
>>> 	  ceph (<= 0.94.2),
>>> Breaks: ceph (<= 0.94.2),
>>>
>>> I think it achieves the same thing and is less error prone in the case of backports. The risk is that upgrading from v0.94.2-34 to the version with this change will fail because the conditions are satisified (it thinks all versions after v0.94.2 have the change). But the odds of having a test machine with this specific version already installed are close to non-existent. The odds of us picking the wrong number and ending up with something that's either too high or too small are higher.
>>>
>>> What do you think ?
>>>
>>
>> -- 
>> Loïc Dachary, Artisan Logiciel Libre
>>

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]