Josselin Mouette <j...@debian.org> writes: > Russ Allbery <r...@debian.org> wrote:
> If GNOME supported being built without those features, yes, it's > fairly straightforward. I probably overstated it by saying it's > trivial, but I don't think it would be that hard. But that's > from the *packaging* perspective, which is the part of the > ecosystem that you were addressing. > > GNOME upstream has not chosen to make those features optional, > for reasons of maintainability at their end, so it's not > trivial, but not for any packaging reasons. Rather, it's not > trivial because the support for acceptable degraded operation > without that functionality is not available in the upstream code > base so far as I know. (GNOME maintainers should correct me > here if I got the situation wrong.) > I haven’t tested, but I think you can start a GNOME session without > systemd-logind and do some basic things. It’s just that the amount of > functionality that is not available makes it unacceptable. Things like > power management (including being able to suspend or shut down), or > network roaming, are not optional except in special cases. You cannot > ship that and expect users to consider it “working”. Ah, okay, so it's not quite as complete as I had thought, but the level of functionality missing from the non-logind branch is sufficiently huge that it's not clear that the resulting packages would be considered useful, or considered GNOME. I think it's fair to call that software that's not been ported to a non-logind world. The porting effort that we're currently doing is to port logind to sysvinit, rather than trying to port GNOME to something other than logind. I seem to recall some discussion in release-team about the status of GNOME on kFreeBSD, which should provide a reasonable glimpse into what GNOME looks like without logind (although it may have even more issues on kFreeBSD than on Linux without logind since a few other things are also different). > This is mostly about functionality that used to be provided by > ConsoleKit. Note that the primary GNOME component affected, which is > GDM, has fallback code for ConsoleKit at runtime. However, everything > else depends on PolicyKit, which has chosen to only allow one of both at > build time. But this is a choice of fd.o developers, not GNOME ;) Whoops, sorry, I had forgotten that there are multiple upstreams involved here who are making various different choices about what's supported. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioj4gc48....@hope.eyrie.org
