On Sat, Oct 14, 2006 at 11:51:49AM +0100, Wookey wrote:
> On 2006-10-14 12:06 +0200, Ingo Juergensmann wrote:
> > 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).
Granted.
> > 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.
Other archs may follow as well. S390 seems short of porters/developers,
mips, alpha, hppa and ia64 don't have such huge userbase either. PPC may be
fade away as well, now Apple made the switch, although there are still some
brave manufactures left for PPC Desktop machine, but those don't have the
market share (yet).
Hopefully it won't end in a i386/amd64 only distribution....
> > 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.
Yes. Even on m68k we get some user input from time to time saying something
like "I'm using firefox on m68k..."
> 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)).
I think it should be done on a per arch basis. The need for desktops can
vary much across archs. i386, amd64 and ppc have a higher need for desktop
apps than arm and m68k.
Generally I would like to see a new release scheme anyway: define a basic
set of packages forming a core release and allow subprojects like desktop
teams (KDE, Gnome, XSF) to do their own releases based on the core release.
But that's a different story...
> Perhaps debtags could be used as an appropriate classification
> mechanism.
Debtags are aiming at binary packages, as someone already stated, and w-b
doesn't support them, but something similar could be implemented for source
packages, I think.
Currently, w-b supports some sort of prioritization, IIRC, so it should
fairly easy to define a certain set of packages at a higher priority (the
core packages if you like). Everything above that priority is considered as
a release criteria whereas every package below that priority *can* be built
and *can* considered for a release for that particular arch - or considered
not.
> 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).
Shrinking packages would be a general benefit for smaller/slower archs as
well. Packages are getting bigger and bigger, so no wonder slower archs are
falling behind. Heck, even on faster archs this does matter. My 512 MB PPC
machine is using >300 MB swap now, whereas it was using no swap 2 years ago
or so.
> And any such descisions have implications for how the release process
> is managed.
Of course. And therefore I would welcome if any of the RMs would join the
discussion. :)
> 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.
Indeed. And a new release scheme will most likely shorten the release
cycles, if done properly. The whole project would benefit from that.
--
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]
