Documenting packaging, plus a few thoughts

[jutty]

I've been through my first full contribution flow from trying to figure things out to submitting a PR. I know things are still being set up so I don't mean to rush anything, just sharing some thoughts:

Perhaps, for a contributor who has never also contributed to Chimera Linux, the current information on how to contribute might sound a bit vague. The actual in-depth and actionable information in in the README of glibcports, which may not be immediately clear. I think we could already improve the Contributing docs with some basic information to make it less terse, and would be happy to provide a PR if that's something that sounds like a good idea.

For instance, the information on "Reduced package set in user repo" section in Known issues is helpful (I'd even move it to the top given it can throw you off a bit as you start looking for things and trying to install them), but I believe it could be expanded on in the Contributing docs, including some pointers on how to "build, install and test locally" (without duplicating existing upstream docs) and setting some expectations and things to be aware of aside from "it runs".

Unrelated to this hypothetical PR, just more thoughts:

I feel the answer to "Will Casuarina accept packages rejected by Chimera?" can feel a bit limiting to a new contributor, or even self-defeating. Low compatibility with the musl ecosystem would cause a package to never reach the cports pull requests anyways, so it's not like they are getting rejected on that basis. I agree with the answer, but feel it could be misinterpreted to mean "Casuarina will not/is unlikely to accept anything that is not accepted by Chimera first", which, I hope, is not the intended meaning?

On this point, while testing niri on Casuarina today, it got me thinking: how strict will Casuarina be about patching upstream? For example, if you install niri as-is today, you will not pull xdg-desktop-portal-gnome as a dependency. Well, that will cause niri to be unable to share the screen on meeting websites. But if you try to manually install xdg-desktop-portal-gnome you'll notice that it pulls an obscene amount of packages including gnome-desktop and all its friends. On Debian you'd end up only having to pull nautilus with it, and on Fedora you'd be able to just get the portal and its dependencies, which seems more sensible to me. My question being: are we tied to whatever is decided upstream?

As you can see, my head keeps thinking thoughts, and they are spilling. I'll leave it at that. I'm excited about Casuarina! Thank you again for sharing it with the world. May it grow strong and healthy roots.

[wezm]

Perhaps, for a contributor who has never also contributed to Chimera Linux, the current information on how to contribute might sound a bit vague. The actual in-depth and actionable information in in the README of glibcports, which may not be immediately clear. I think we could already improve the Contributing docs with some basic information to make it less terse, and would be happy to provide a PR if that's something that sounds like a good idea.

Yes the content that's currently present was just the first pass by me to get the site up. Enhancements like including more information or pointers to existing info on the Contributing page are welcome.

I feel the answer to "Will Casuarina accept packages rejected by Chimera?" can feel a bit limiting to a new contributor, or even self-defeating. Low compatibility with the musl ecosystem would cause a package to never reach the cports pull requests anyways, so it's not like they are getting rejected on that basis. I agree with the answer, but feel it could be misinterpreted to mean "Casuarina will not/is unlikely to accept anything that is not accepted by Chimera first", which, I hope, is not the intended meaning?

No that's not the meaning. It's referring to things that have been explicitly rejected from Chimera such as this. As per https://casuarina.org/docs/policies/#upstreaming it's fine for packages to only exist in Casuarina. It would be great for packages that have a broad appeal to go to Chimera too, but it's not a requirement.

On this point, while testing niri on Casuarina today, it got me thinking: how strict will Casuarina be about patching upstream? For example, if you install niri as-is today, you will not pull xdg-desktop-portal-gnome as a dependency. Well, that will cause niri to be unable to share the screen on meeting websites. But if you try to manually install xdg-desktop-portal-gnome you'll notice that it pulls an obscene amount of packages including gnome-desktop and all its friends. On Debian you'd end up only having to pull nautilus with it, and on Fedora you'd be able to just get the portal and its dependencies, which seems more sensible to me. My question being: are we tied to whatever is decided upstream?

We are not strictly tied to what's decided upstream. I've already made some choices like moving stuff out of main or switching a package to use memory safe TLS instead of OpenSSL. Ideally we don't diverge too far though, so it's still straightforward to keep in sync. It's early days though, so we'll how this all shakes out.

For things like the portal I see a couple of possible scenarios:

1. It's like that for a particular reason, which we should understand first
2. It's like that for an accidental reason, and is open to being changed
3. We're misunderstanding something

In this particular case, I believe xdg-desktop-portal-gnome exists for GNOME, so perhaps xdg-desktop-portal-gtkis the better choice. My guess as to why niri doesn't depend on a particular portal is so that you can choose whichever you want.

As you can see, my head keeps thinking thoughts, and they are spilling. I'll leave it at that. I'm excited about Casuarina! Thank you again for sharing it with the world. May it grow strong and healthy roots.

Thanks for trying it out and sharing your thoughts as well as being the first person to open PRs.

[jutty]

Thank you, Wes. That's encouraging.

In this particular case, I believe xdg-desktop-portal-gnome exists for GNOME, so perhaps xdg-desktop-portal-gtkis the better choice. My guess as to why niri doesn't depend on a particular portal is so that you can choose whichever you want.

I initially thought so too, but in niri's case you specifically need xdg-desktop-portal-gnome for screen sharing.

Just as an example though. Other quirks like how installing the linux-* packages pull every single firmware package come to mind, but granted these are all things that deserve being looked at on their own in due consideration. It's good to know that we are not as coupled to Chimera as I initially felt.

[wezm]

The firmware handling is by design. It pulls it all in by default for the common case of allowing everything to work automatically. However if you know the specific devices you need to support, you can mask the firmware meta package and add the specific firmware you need (if any).

[gasiyu]

Thank you, Wes. That's encouraging.

In this particular case, I believe xdg-desktop-portal-gnome exists for GNOME, so perhaps xdg-desktop-portal-gtkis the better choice. My guess as to why niri doesn't depend on a particular portal is so that you can choose whichever you want.

I initially thought so too, but in niri's case you specifically need xdg-desktop-portal-gnome for screen sharing.

Just as an example though. Other quirks like how installing the linux-* packages pull every single firmware package come to mind, but granted these are all things that deserve being looked at on their own in due consideration. It's good to know that we are not as coupled to Chimera as I initially felt.

Even the docs say so, there's no hard dependency on xdg-desktop-portal-gnome. You can override the screencast portal definition in niri-portals.conf with your choices, for example xdg-desktop-portal-wlr, and it works fine for screencasting.

[jutty]

Thank you, Wes. That's encouraging.

In this particular case, I believe xdg-desktop-portal-gnome exists for GNOME, so perhaps xdg-desktop-portal-gtkis the better choice. My guess as to why niri doesn't depend on a particular portal is so that you can choose whichever you want.

I initially thought so too, but in niri's case you specifically need xdg-desktop-portal-gnome for screen sharing.

Just as an example though. Other quirks like how installing the linux-* packages pull every single firmware package come to mind, but granted these are all things that deserve being looked at on their own in due consideration. It's good to know that we are not as coupled to Chimera as I initially felt.

Even the docs say so, there's no hard dependency on xdg-desktop-portal-gnome. You can override the screencast portal definition in niri-portals.conf with your choices, for example xdg-desktop-portal-wlr, and it works fine for screencasting.

I understand that, my mention of xdg-desktop-portal was about its dependency on gnome-desktop in Chimera, which, unlike other distros, makes you unable to install that specific portal without pulling GNOME, which is not really needed for the portal to work. It's not about whether or not you can use a different portal with niri, more like one example among many possible packaging decisions.