Re: How should we deal with 'pointless-on-this-arch' packages?
On 2006-10-14 12:06 +0200, Ingo Juergensmann wrote:
> On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote:
> 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.
No - but they might well run it on an Iyonix, and maybe even a
balloon. Even though arm is mostly-embedded there are a few desktop
machines (which merely illustrates the problem of general
package classifications).
> 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.
As you say m68k is leading the way in terms of still being a useful
arch but not able to cope with 'all of debian'. Arm is following.
> 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, ...)
Clearly something like this could be a general solution to the
problem. I do think there is value in defining characteristics of
packages so that choice can be made, but it is not an easy thing to
do. Even on a slow arch which is not normally used as a desktop,
desktop packages are often needed.
Should such classification be done per-arch, or generally. Should
we perhaps have 'core' and 'other' (like ubuntu's main and multiverse
(or whatever it which)).
Perhaps debtags could be used as an appropriate classification
mechanism.
Perhaps embedded debian could be developed to fill the 'smaller
machine' niche, although that is not necessarily a very good fit
(emdebian is about shrinking all packages as well as subsetting).
And any such descisions have implications for how the release process
is managed.
Nevertheless I think it is clear that we do need mechanisms to keep
the load and package set appropriate for slower arches. If we design
the mechanism properly I would hope it could be useful for various
categorisation/subsetting purposes within debian.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://wookware.org/
Reply to: