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
signature.asc
Description: OpenPGP digital signature
