On Tue, Mar 04, 2025 at 04:53:36PM GMT, Stuart Henderson wrote:
> On 2025/03/04 17:46, Landry Breuil wrote:
> > Le Tue, Mar 04, 2025 at 05:13:07PM +0100, Tobias Heider a écrit :
> > > Hi,
> > > 
> > > here is a new port for niri [1], a scrollable-tiling Wayland compositor
> > > heavily inspired by the PaperWM extension for Gnome.
> > > 
> > > This one is a little different than our existing wayland compositor ports
> > > since it doesn't use wlroots but smithay [2] as its underlying compositor
> > > library.
> > > 
> > > Smithay is written in rust and pulls in quite a few dependencies, I had to
> > > resort to some hacks to make it pick up the patched OpenBSD compatible
> > > versions since most patches haven't found their way into an upstream 
> > > release
> > > yet. In the current version I fetch niri itself and all the patched
> > > dependencies from my forked trees on github. I already got some of them
> > > merged upstream so I'm optimistic that we can swtich over to an official
> > > release in the near future.
> > > 
> > > Looking forward to get some feedback.
> > > Some open questions:
> > > Is there a better way to handle the rust dependencies?
> > > Would it make sense for a large rust package such as smithay to be a 
> > > separate
> > > port?
> > 
> > if that's installed as a lib that can be used by other ports, yes. if
> > it's only to ship the source as a buil dependency, i dont think it fits
> > well with the rust ecosystem..
> 
> That would just be a copy of the source code, and wouldn't be any use
> in ports. The only time we have those is for special cases (like
> rust-openssl-tests which includes rust src and is used for regression
> testing).

I was thinking more like a static library that is only used as a build
dependency but I'm not sure if that is possible in rust.

> 
> > > I used upstream_version.date for our port version, is there a better 
> > > solution?
> > 
> > that's what i also usually do, or 'pl0' for 'patchlevel' when you have
> > modifications 'on top' of upstream.
> > 
> > the port itself already looks quite good, as for the configuration file
> > you might want to @sample examples/niri/default-config.kdl to
> > /etc/niri/config.kdl so that it's there by default.
> > 
> > generally speaking, i think it's good to have wayland compositors in
> > port that are not based off wlroots, allows for wider testing.
> > 
> 
> I've done approximately 0 with wayland but that makes sense to me.
> 

Reply via email to