Re: RFC: Debian GNU/kFreeBSD and Jessie
On 01/02/2014 15:19, Dimitri John Ledkov wrote:
>> Here's what I think of as a problems that may need to be fixed by reaching
>> an agreement with -release:
>>
>> 1. Some application-level software is growing hard dependencies on SystemD
>> or other Linux-specific components (e.g. X->udev, gdm3->systemd).
>>
>
> The second example is also incorrect, as it's "gdm3 -> logind" not
> systemd, if we follow the first one and drop "systemd-" prefix.
>
> There is a logind shim uploaded, if it FTBFS on kfreebsd, it should be
> investigated.
What degree of support for this codepath have? If e.g. Ubuntu is going to rely
on it, then we know it's something we can rely on too.
If it's just a potential for bitrot like hal/consolekit, I think we should steer
away from it.
> I dislike disabling testsuites. I believe "nocheck" behaviour is also
> incorrect, test-suites should always be compiled and attempted to be
> executed. And the only thing that "nocheck" and/or debian rules should
> control is weather to fail the build or not. As otherwise there are no
> records / information of what is failing.
I completely agree, but it seems that -release doesn't. From what they
previously said I gather that they expect "whether to fail the build or
not" decisions to be consistent across ports.
Perhaps we can disable individual tests on a case by case basis, but
unfortunately this would require investigation of the test, which is
time consuming.
> Whilst we can discuss scope reductions and individual problems, i'd
> like to understand in practical terms how it can be implemented.
I can't think of a solution to this problem with the instrument -release
is giving us.
Unless someone has a bright idea I guess we're stuck with it? :(
> If
> thinking in those terms, I believe e.g. hal & consolekit can be
> declared as not supported across all ports (bugs not considered RC,
> does not block testing migration) and all ports should strive to
> migrate to other solutions (e.g. be it devd or udev or something else
> or be allowed to keep using obsolete components until sombody does the
> work for the "reduced in scope ports").
When discussing testsuites, I was thinking more on things like glib, which
we can't avoid no matter what.
For HAL & consolekit, and in general everything that is declared as dead
or abandoned by upstream, perhaps we should strive to completely get rid
of this kind of components?
HAL seems relatively simple to get rid of without regressions. The only
things it was supposedly good for, don't actually work (see #736765, and
also notice how desktop volume managers don't handle automount either).
As for consolekit I'm not sure. What use cases does consolekit intend to
support which aren't covered by traditional approach? (e.g. as in XDM)
I assume this is about a single computer with multiple user seats? I suspect
nobody has even tried this use case on GNU/kFreeBSD, and I wouldn't be
surprised if it didn't even work.
--
Robert Millan
Reply to: