On 31 January 2014 21:33, Robert Millan <r...@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. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjs5S8Hhw6vxihd8R=sq6e7dw_jysn0jq320gxvpda...@mail.gmail.com
