Re: Debian Archive architecture removals
[Speaking for the debian-hurd team]
Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit :
> Maybe it's just about supporting and advertising debian-ports as
> Debian's official way to host second-class architectures. Maybe
> there's more to it. What are the current downsides of moving hurd-i386
> and sparc to debian-ports?
That's perhaps the best question to address. Being on master just for
being mirrored is not useful to such kinds of ports of course. In the
current status of the Debian infrastructure, there are however a lot
more consequences, which we can perhaps work on, so as to avoid making
hurd-i386 and sparc essentially disappear, and perhaps at the same time
to revive some debian-ports archs without overhead for ftp-master,
d-release etc.. Also perhaps more easily consider removing more archs
from master.
* Appearing on packages' and maintainers' PTS
pages like http://buildd.debian.org/bash and
https://buildd.debian.org/sthibault@debian.org
This makes people aware of portability issues; when hurd-i386 moved
there some years ago, that did make a change: we saw maintainers
caring and fixing their packages, quite often the fixes are quite
trivial. It would be useful to see other debian-ports results there
for portability checking, notably hppa. There is already a link to
buildd.debian-ports.org, but people do not even notice it, let alone
think about checking it.
* Getting binNMUs from d-release transitions
This saves porters a lot of tedious work that would otherwise be just
duplicated. We are not talking about fine-grain binNMUs here, but
coarse-grain well-known planned binNMUs. Wanna-build supports extra-deps
which makes it easy for d-release to just throw them at debian-ports
archs along the master archs and forget about it.
Those two previous items may actually perhaps be fixed together:
could it make sense to have the debian-ports architectures on
buildd.debian.org, would it bring human overhead? The databases there
are already per-architecture, so they don't actually interfere.
* Appearing on http://release.debian.org/transitions/ and
https://qa.debian.org/dose/debcheck/unstable_main/index.html
We're fine with d-release not looking at the hurd column. But *we*
however do look at it, and would be sad to completely lose that. It
could be in a completely separate page or column, that would not pose
problem.
* Being considered as "second-class citizen"
Well, this is already rather true for hurd-i386: we do sometimes
get answers from maintainers "this is not going to be a release
architecture, I will not bother with patches for it" (even about
packaging patches). Or the patches linger on the BTS for years (see
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd)
Currently we use the "important" severity for hurd-i386, but maintainers
can just discard it.
Being on debian-ports actually somehow partly helps here, since we can
upload patched packages in "unreleased" and continue porting. But on the
other hand this makes us less pushy, and patches tend to accumulate.
Also, being on debian-ports makes it much more difficult to afford
making binNMUs, and thus the patches can really linger in the BTS ad
æternam.
Perhaps we need a political decision here?
Samuel
Reply to: