Re: How should we deal with 'pointless-on-this-arch' packages?
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: 2744150@sipgate.de
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
Reply to: