On Tue, 2012-06-19 at 21:33 +0100, Adam D. Barratt wrote: > On Sun, 2012-06-17 at 19:16 +0000, Laszlo Boszormenyi (GCS) wrote: > > On Fri, 2012-06-15 at 15:33 +0200, Bastian Blank wrote: > > > The ceph upload in NEW tells: > > > | * Limit archs to build on as leveldb dependency doesn't support all. > > > The leveldb package is clearly not restricted to specific architectures, > > > so this is not allowed. > > While I agree with this, I don't see the point how leveldb and ceph > > will migrate to testing. > > The same way they always have? The requirement is that the package is > up to date _on the architectures on which it has previously built_. > Failure to build on architectures on which the package has never built > is irrelevant.
(Having hit send a little too soon) Note that whether you use an explicit architecture list or "any", if the new set of architectures on which ceph builds drops support for some architectures then you'll need to ask ftp-master to remove the old binaries from unstable before the package can migrate. Making the package "arch:any" doesn't introduce the obstacle to migration, the restriction to a particular set of architectures (either explicitly or implicitly due to using an unported build-dependency) does. I assume from your comment that you're expecting that an explicitly architecture-restricted ceph would be eligible for testing migration with no further intervention; that's not the case, as detailed above. > > In my opinion, leveldb should be limited to > > architectures that it builds on. Do the porting in the background and > > enable others when they are ready. If I upload ceph and it can't be > > built because of leveldb doesn't support that particular architecture, > > then the effect is similar. I just put a job on buildds that it won't > > even start. > > They're really not the same. > > With both packages set to "arch:any", ceph will indeed not build on any > architecture where leveldb isn't available - that's presumably already > the case though. This doesn't put any load on the buildds, as ceph will > be marked as "BD-Uninstallable" on those architectures and not be > available for a buildd to pick up. > > The difference comes when a future upload of leveldb (or a fix in one of > its dependencies, or the toolchain, or the phase of the moon) means that > it manages to build on a new architecture. With your solution, this > requires a new upload of ceph in order to add the new architecture; with > the package as arch:any, ceph automagically gets a build attempt on the > new architecture with no intervention from anyone as the buildd software > will notice that leveldb is now available. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
