i'm both not surprised and extremely pissed
this attitude is just the worse too
RE: https://hachyderm.io/@jorge/116619028047490652
@navi If it makes you feel any better, as far as @novenary & I could tell, Jorge Castro is neither a Flatpak v1 nor a Flatpak developer. He is a Universal Blue developer, though, which I would say explains the extremely callous attitude and lack of care for use cases outside of his vision. This aspect of Universal Blue's project leadership really is the worst part of Universal Blue, in my opinion. (I respect their work with Bazzite & friends, and am writing this post from an Aurora box, but I still wish to never see other projects replicate Universal Blue's hardheartedness. Your project & community would be better without it.)
I would very much expect the Flatpak developers who actually gave the Flatpak-Next talk at Linux App Summit, @AdrianVovk & @swick, to be much more reasonable about accepting support for distributions that don't use systemd into Flatpak-Next. (As an example, Sebastian Wick's SO_PEERPIDFD Gets More Useful blog post (2025-10-10) explicitly discusses how a new Linux kernel feature not being systemd-specific is a good thing, and discusses a bit how support might work on kernels other than Linux. Flatpak Happenings (2025-11-04) states a plan to “Make varlink a feasible alternative to D-Bus”.) AFAICT, Flatpak-Next's use of systemd is the normal, pragmatic kind, where their interest in systemd is in how it offers a standard interface across a large number of Linux desktop distributions, and is not a belief that systemd should be the only option for a Linux desktop distribution.
I'd appreciate clarification from @AdrianVovk and/or @swick about Flatpak-Next's goals, expectations, and maintenance desires actually are here.
@bb010g @navi @novenary @swick I expect that we'll have a dependency on systemd through systemd-appd at least. I also wouldn't be surprised if certain parts of the sandbox would have to be turned off if systemd services are unavailable. Of course it's hard to speculate about code that doesn't exist. I would say that you can probably expect similar things to what happened with GNOME's increased systemd dependency.
@AdrianVovk @navi @novenary @swick Alright; sounds reasonable. Would you expect external contributions to Flatpak-Next that enhance support without systemd-appd to be accepted? (Alternatively, might the subset of systemd-appd's API that Flatpak depends on be small and stable enough for reimplementation outside of systemd? personal hope would be a (collection of?) little Varlink interface(s) that systemd-less desktops could target.)
(Also, thank you for such a prompt reply. 
)
@bb010g @navi @novenary @swick I would expect the need for polyfills of Varlink services, rather than code added upstream. Frankly, the ratio of support burden to people benefitting for non-systemd environments is simply too high for us to deal with upstream. Flatpak Next is an exercise in ultimately reducing the amount of code we have, and that means making stronger use of the dependencies we have available to us
Again all very preliminary thoughts about a codebase that doesn't yet exist
the major issue with writing polyfills is that we end up locked into systemd's architecture -- how much of a problem that is depends on the specific api, sometimes it's manageable, sometimes it's almost impossible (i say this as someone currently designing a session manager that will serve as backend for a login1 polyfill)
in those cases, ideally, imo, would be for instead of a polyfill, have an alternative project that is init agnostic (e.g. how we have seatd, and soon this session manager i'm working on)
we already have UAPI, some parts like the bootloader or uki spec are part of it, why not draft a new spec together that systemd can implement as appd and non-systemd systems can implement some other way?