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