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.
Agreed.
> 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).
Same for m68k. Additionally such packages like flightgear don't make much
sense on those archs.
> No-one in their right mind would run numerical analysis on an arm box,
> for any purpose other than testing that they could.
... or to find bugs.
> Now in an ideal world we would gratutiously build these packages
> anyway, just to check that they do build on said architecture, but
> 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.
Very true, especially before freeze when every maintainer uploads frequently
to get new and hopefully bug-fixed version in...
> 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'.
Placing a package in N-F-U is mostly done for FTBFS reasons or if upstream
doesn't support that arch.
> 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?
I think "yes, it should be... to some degree at least..."
> Should we perhaps have a more general mechanism than such ad-hoc
> marking to indicate innappropriate combinations of package and
> architecture?
> An example of this genre is fityk, which currently times out on arm,
> trying to build large C++ files. It is curve-fitting software. It
> could probably be built, but one wonders if it is worth the effort.
> The author is happy to not have it built for arm.
> I'm sure there are others in the same situation, although I have not
> done extensive research to try and produce a list.
I believe the Vancouver proposal went into wrong direction by excluding
(slower) archs from releases. Of course, dropping archs is a quick and easy
way to lighten the load for a release, but IMHO it is wrong, because it's
damaging and destroying one of Debians biggest strengths: being an universal
OS that can be run on nearly every arch.
Of course nobody wants to extent the releases beyond any sane time just due
to some slower archs. The question is: how can Debian release more
frequently and on time even when some slower archs are falling behind and
can't keep up with >6100 source packages?
The answer is quite simple: reduce the load for those archs by not forcing
them to build *every* package, but only a certain subset of them.
I think everyone will agree that every arch should have a basic set of
packages to be suitable to use it like some shells, some editors, ssh,
debian-installer, compilers, linkers, etc.
It doesn't make much sense to build all Desktop related packages for an arch
that is mainly used remotely or as an embedded device. I don't think that
anyone will run KDE on top of an NSLU2 or on a Linksys WRT54G.
Same may be valid for m68k, although there *are* users that are using their
m68ks as an X-Terminal or such. But those are rare.
So, it's better, IMHO, to reduce the number of packages for those archs by
defining some sort of requirements:
- what is *required* to make use of that arch (f.e. example packages in
section base, admin or with priority required)?
- what is commonly used on those archs? popcon can gives some hints like
MTAs, fetchmail, UUCP, DHCP-stuff or similar things (gcc, debugger, ...)
- what is rarely used? (Desktop Environments, Browsers, numerical analysis
tools)
- what is unuseable on that arch? (qemu, Xen, flight simulators, cluster
software, ...)
When an arch doesn't need to have *all* of the archive to build, like KDE,
Gnome, the arch (and the porters!) have more resources to get the important
packages being build.
*If* resources aren't exhausted, the arch *can* build stuff that isn't that
necessary for that arch and its users. And even more, if it can be released
with the other archs, the users are happy and being able to compile needed
packages on their own if they need some other packages, that haven't found
their way into the release for that arch.
M68k was the first port that got released by Debian and it's the first arch
that got dropped from the release. And it showed now that it's unclear how
the port should be handled after the drop. Can it be released in a
point-release later? Does it need to wait for etch+1?
I think m68k just made the first step and other archs will follow being
dropped from Debian, despite the possible return as a combined m68k/coldfire
port. Debian has way too many packages and too few porters for
non-mainstream archs to cope with that load.
But sadly, I have very little hope that Debian will change anything it's
release structure soon. *sigh*
--
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]
