Re: Upcoming changes to supported architectures
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have a local mirror of m68k, and both kfreebsd ports, and they're
roughly 70-80GB including source. If ries has become so full that
space is becoming an issue, then dropping arm, hurd-i386, and m68k is
a stopgap move at best (your only going to recover maybe 50GB, 10 for
hurd (it only has half the archive built), and 20 each for arm and
m68k).
As for CPU usage and RAM, I'm not really seeing it; dak itself only is
"executed" during dinstall, where automatic processing of all dak
queues are run. GPG signatures are checked during import, which should
not be much of a burden. The only thing that should be CPU intensive
is apt-ftparchive generate, and only when importing a new archive or
rebuilding the packages files after trashing the cache files (on
modest hardware, it takes apt-ftparchive to do a full rebuild of an
architecture roughly 40 minutes, but unless there is an issue with the
caching, I don't see what the burden on resources is.
As for chopping up the archive into subsections, dak itself can handle
managing multiple archives pretty well (I'm not sure how great it is
about moving stuff from section to section, but that can be fixed with
a simple python script). It makes sense for me that each section that
already exists could be divided, so instead of say, just unstable,
have unstable-net, unstable-devel, unstable-base, etc. This has the
wonderful added bonus that having a new architecture could have their
own testing for sections they have fully built. For some of the larger
package groups (KDE, GNOME, XFCE), those can each be their own
section.
Each architecture's porters can choose what sections to include. I'd
say go one step farther and have a release manager appointed from each
section to handle that release; which has the added bonus of also
revealing the workload on the current RMs. Priority should determine
if something MUST be present to do any release. Pretty much make it so
anything that is Priority required or higher must be built, and the
rest is up to the architecture porters.
As for architectures wanting to get into debian, shX is currently
looking at least four ports just to handle the subarchs (that's a
discussion for another time), netbsd-* is dead (has been since '02),.
kfreebsd-* is pretty close to releasable; they've got the archive
built in the high 80s, and are keeping up).
It seems to me the current policy of the ftp-masters is to only accept
a port once its fully built and releasable; armel is the only
relatively new port, and that was completely staged on d-ports, and
didn't join sid on the archive until it was reasonable. When did it
that become debian policy? Running a dak server is not the easiest
task in the world (d-ports uses mini-dak), and configuring and
managing a local wanna-build isn't that easy, especially considering
there is virtually no documentation, and a lot of of it is trial and
error. All other ports were built within sid itself, hell, m68k was
the first port of debian, which created the buildd and wanna-build
infrastructure alll other ports use!
An added note on this subject is the constant trouble of adding SSH
keys to buildd.d.o. and general wanna-build administration. hurd-i386
currently hosts their w-b on debian-ports, and m68k has had constant
issues getting keys added to the point of sheer lucidity. How hard is
it to copy and paste a few lines into buildd-m68k authorized keys? It
just seems that any more with less then 100 users seems to be well a
second class citizen. A part of me wonders when other ports with
limited userbases are going to start getting dropped; for me, one of
the biggest strengths of Debian was the fact that it runs on pretty
much everything (only Gentoo can match in platforms supported at last
count).
As for dropping architectures, this was proposed as part of the
vancouver proposal, but I don't understand why we're following this if
the rest of the proposal was NEVER implemented. According to the
proposal, the four most popular architectures (i386, amd64, ia64, and
powerpc) would remain on ftp-master, and the rest would become
second-class citizens, and be moved to scc.debian.org. That same
server would also run a full blown dak and handle accepting new
architecutres. As far as I can tell, that never happened, and debian
simply changed that architectures must be fully bootstrapped and built
before they will be accepted vs. just requiring three DDs to advocate
the port.
I also read that doorstop.debian.org would be created for hosting
newer architecture, which would run dak and such; again, never
implemented. Right now,all we have debian-ports, which isn't even an
official Debian service for hosting new architectures, and is
currently maxed out.
If the problem with adding new architectures is that reis is maxed
out, the solution is not dropping old architectures, its upgrading the
server since just removing older ones is a stopgap solutions at best.
I've been told there is money in the bank for such a thing to be done,
and I'm fairly sure that even if their isn't, money could be gathered
towards buying new harddrives or whatever else is needed for reis.
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org
iEYEARECAAYFAkilghAACgkQpblTBJ2i2psjfgCgkLlYnCIUolF7mz0HcZDTco6+
26gAnj+yHu1ZCdGJ2Ym8XJWHRZBJ8dBw
=X0J5
-----END PGP SIGNATURE-----
On Fri, Aug 15, 2008 at 6:36 AM, Ingo Juergensmann
<ij@2008.bluespice.org> wrote:
> On Fri, Aug 15, 2008 at 06:45:30PM +0900, Charles Plessy wrote:
>> Le Fri, Aug 15, 2008 at 09:59:01AM +0200, Ingo Juergensmann a écrit :
>> > I believe that changing the release scheme to not release the whole archive
>> > in one release but do some sort of subreleases (base, X, database, ...) is
>> > not going to be considered as "sane alternative"... ;)
>> That is sad, I would love it to happen... The management of the userless
>> packages on specialised arches is a time sink that in addition
>> poisons the relationships between package maintainers and porters
>> (or at least between me and the porters). I really think that we should
>> be more user-driven for these issuses: If users want some categories of
>> packages, let's work hard to provide to them. If nobody shows up...
>> let's concentrate on other issues.
>
> Well, currentlz the porters can add packages to N-F-U, which originally is
> intended to store information that is not suitable for some archs, e.g.
> because of missing hardware or something similar.
> "Abusing" N-F-U for exclusion of "unwanted" packages is a workaround maybe,
> but not a good one. Currently Debian lacks the ability to release a subset
> of packages for some archs. For example I think XFCE4 would be sufficient to
> most users on m68k when they want to use X11 on their machines. That means
> that non-depending packages for Gnome, Wmaker, KDE could be build on a
> best-effort basis and stored somewhere else on separate/willing mirrors.
>
> If that would be possible a lot of porting work could be saved (as in
> building those packages on these slower archs and dealing with bugs) that
> could be spent in porting more important issues (like glibc, binutils,...).
>
> This would, of course, break with the current "build all packages on all
> archs and let the users decide" policy in some way, but it gives a better
> flexibility and aims at subrelease scheme, where the archive is split up
> into subsections (as they are present yet) and being able to release those
> in separate release (base, important, X11, Desktop, KDE, Gnome, databases,
> ...).
> This would benefit the users because the base system could be released every
> 2 years for example whereas the desktop related sections could be released
> more often.
> Yes, of course this means a lot of work to do and I dont know if this is
> doable with the current ftp-master infrastructure, but I think it`s
> solvable/doable and Debian would benefit in the long run as well.
> The archive will be ever growing and dropping archs when space gets limited
> is not a good solution to this problem, IMHO...
>
> --
> Ciao... // Fon: 0381-2744150
> Ingo \X/ SIP: 2744150@sipgate.de
>
> gpg pubkey: http://www.juergensmann.de/ij_public_key.asc
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: