On Sat, Oct 14, 2006 at 05:35:57PM -0400, Kevin Mark wrote: > > 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)
Feel free and invited to join the buildd.net development process! A dependency resolver and other things are already on the todo list, but I'm short of free time for those features. :) > 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. Yes, removing some packages from being a release criteria would certainly help, although we had huge toolchain issues in the past on m68k. gcc-4.0 was absolutely no good choice for m68k and introduced many, many FTBFS errors. > > 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 ? IMHO porters and RMs should decide this issue. > > 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? W-b has some sort of priority for packages, which made be (ab-)used for this. But that's of course no dependency-resolver as it was proposed for other w-b replacement projects. [0] > > 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? IMHO: yes! [0] http://www.buildd.net/files/Multibuild-Draft.pdf -- Ciao... // Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
