Re: RFC: Debian GNU/kFreeBSD and Jessie
On 31 January 2014 21:33, Robert Millan <rmh@debian.org> wrote:
>
> -release asked us to discuss a possible solution among ourselves so we can
> propose it to them. But the problem is not clearly defined yet. So I thought
> maybe we can do some progress by discussing what the problem is.
>
> 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.
> 2. Sometimes this software provides alternative setups, but they're poorly
> maintained (if at all). We're often stuck (not really) maintaining them
> and the result is bug-riden user experience. (e.g. X->hal, gdm3->consolekit)
>
> 3. Too many testsuites fail for us. Sometimes because they found genuine
> bugs in our port, but often just because of portability bugs in the tests
> themselves. Maintainers often respond by disabling the testsuite (or allowing
> it to fail). This worries -release because it jeopardizes their QA efforts.
>
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.
Whilst we can discuss scope reductions and individual problems, i'd
like to understand in practical terms how it can be implemented. As
far as I understand, a reduced scope, will still be a release
architecture yet a subset of packages will not meet release criteria,
so will that subset of packages will not result in kfreebsd-any bug be
RC and/or otherwise not block complete migration to testing? 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").
Regards,
Dimitri.
Reply to: