Re: Bits from the Release Team: Architecture health check
On 2014-01-30 16:23, Robert Millan wrote:
> On 30/01/2014 00:03, Niels Thykier wrote:
>> @Robert: Re your "Could you elaborate?". I haven't forgotten it, but I
>> out of time - so I will get back to you on that.
>
> It's ok.
>
> I wanted more detail both on the problem and on the solution. You just provided
> the second, which I believe is the most important.
>
Okay - as promised, the problem side.
As I see it, there are two concrete problems with the (number of)
supported packages. First, the number of packages actually built on
kFreeBSD is just shy of 90%, whereas most other release architectures
are at 96%[1]. Here kFreeBSD has increased in the past quarter from
~89.5% to "almost, but not quite 90%".
Secondly, there are cases like GDM, where a single unsupported package
have rather "long reaching" consequences. In the concrete example,
GNOME (via gnome-core) strictly depends on gdm3, meaning that if gdm3
goes, (more or less) all of gnome goes with it[2]. That in turn means
that task-gnome-desktop cannot be installed on kFreeBSD (I presume this
will at least affect d-i).
Here we need you to assess what can you reasonably support. Once we
know that we can look at the consequences and how to deal with them.
By the way, when you present your set of supported packages, please
consider highlighting where you would like the "default" package set to
be different from current release architectures. E.g. with the TC's
decision on init systems, Linux will be using systemd as default init
system[3]. I presume kFreeBSD will go with a different init system.
~Niels
[1] https://buildd.debian.org/stats/graph-week-big.png
The notable exception here being s390x, which is at ~93%.
[2] I vaguely remember something XDM being a possible alternative to
GDM, but never mind that for now.
[3] Here I bluntly assume there will not be a GR overturning that decision.
Reply to: