On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: > In general debian builds everything for every architecture. This is a > very good plan and finds a lot of bugs. Hi Wookey, endian bugs, 32/64 bit bugs, int size bugs, more eyes on bad code, more users on bad code, low-mem compiling, low-mem installs, more testing of the Debian infrastrure (apt,debconf,pre/post install scripts) and providing 'practice' for porters x-) These are the 'good' reasons not to do this. > > However there are some packages which are clearly not sensible on some > arches. Numerical analysis software in general on arm is a good > example of this class. Arm hardware is generally slow and more > seriously has no floating point hardware (except very exceptionally). As you say there are lists. I'm aware of p-a-s and n-f-u lists which provide mechanism for things not being built. I'd also be interested in Ingo's wonderful buildd.net that can provide 'what are the top N things that are taking the longest to build' (per arch) (although this does not take into account something like 'kde' which depends upon many bits to be built) I've read that the ftpmasters consider it a bug if someone adds an arch to p-a-s unless there is substantial reason, and n-f-u has a specific use case that would not be suitable for this either. So maybe a new list for packages that are buildd intensive and would not benfit the arch use case for being built -- may call it packages-that-are-too-resource-intensive as I dont see some tiny 10k package being dropped but only large ones. Also, from the graphs on % of packages built, it is normally in 80%+ range for short periods of time while is is more often in the 93%+ range. And the 'cut-off' is IIRC 95%+ as the 'release' requirement. So it should only require the removal of a handfull of very intensive packages to get that number up to release status. > > No-one in their right mind would run numerical analysis on an arm box, > for any purpose other than testing that they could. The question is who should decide and by what criteria? ftp masters, the maintainers, the porters ? > > Now in an ideal world we would gratutiously build these packages > anyway, just to check that they do build on said architecture, but IIRC the buildds do not have a weight attached to each package to determine its order in the buildd queue. Would the introduction of a weight, where resource intensive packages get put on the bottom and are built at 'slow' periods help? > there is a cost to doing this. Buildd time and archive space. Buildd > time particularly, for slow arches, is a resource we don't have a huge > abundance of. > > So, 'is pretty much pointless' has not to date been deemed a reason to > mark a package 'not for us'. However, It seems to me that if the porters > _and_ the package maintainer agree that there really is no real point in > building a package for a particular arch, and it takes signifcant > resources to do so, that it is best to mark such packages 'not for us'. There are currently 'release goals' for the entire project. Would it make sense to have 'arch goals' that would include the exclusion of certain packages that are 'not-for-us' with the 'us' being the team that is familiar with the uses of the arch and what should be build? > > However I don't think we should just start doing this unilaterally, > so I am posting here to canvass opinion. Should inappropriateness be a > criterion for deciding a package is not-for-us? > <snippage> just my 2 centieuros, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System | go to counter.li.org and | | `- http://www.debian.org/ | be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org |
Attachment:
signature.asc
Description: Digital signature