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