Hi, When I initially start writing this wishlist bug report, I was expecting existence of one upstream source tree. The more I checked situation around incus-ui, I concur with your thought and see more challenges for packaging.
Although I have no idea for typescript nor node, I realize that, though the building lxd-ui was trivial task on my local Debian machine, it is a non-trivial task for Debian packaging unless I dare to package many node packages. I found 2 references for existing packaging efforts (ARCH and SPEC for some RPM) * https://gist.github.com/vaxvhbe/ce679df15fc521c8aca1ff9ddf537201 SPEC * https://github.com/KosmX/incus-ui-canonical-arch/blob/master/PKGBUILD ARCH So I tried on my local machine to build unmodified source as a starter: $ sudo apt install yarnpkg npm $ git clone https://github.com/canonical/lxd-ui.git $ cd lxd-ui $ yarn install $ yarn build Then I easily had a static web page with javascript to serve at build/ui/ I realize zabby's patches to make Incus UI were applied to the upstream LXD-UI source, so it wasn't as brute force changes as I was afraid of. But, as I checked in the build tree under node-modules/, there are too many packages (~600) involved. This means there is a heavy burden of creating an official deb package since all these packages need to be packaged in advance for Debian to satisfy the Debian build requirement. Then, on the top of it, there is an issue of maintaining patches as you mentioned. If I will file a RFP, I should do it as a fresh one to get the best exposure (instead of retitle ITP or this bug report.) Let me record few references I found. Debian * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067041 this wishlist bug * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036926 closed ITP lxd-ui Upstream message around web-ui * https://stgraber.org/2023/11/25/adding-a-web-ui-to-the-incus-demo-service/ * https://discuss.linuxcontainers.org/t/web-ui-for-incus/18198/2 * https://discuss.linuxcontainers.org/t/incus-web-ui-spacing/18928 * https://discuss.linuxcontainers.org/t/lxconsole-as-web-ui/19212 * https://discuss.linuxcontainers.org/t/stateful-uis-and-questions-about-lxd-ui-history/18302 Incus upstream doesn't wish to spend his time on this web page generation and maintenance and provided proof-of-concept example by rebranding lxd-ui Incus UI is a single-page application written in TypeScript and React and only replicates what you can do with the incus CLI program (i.e. works through the REST API). Other UI -- all needs external dependencies * https://github.com/PenningLabs/lxconsole (PYTHON) * https://github.com/AdaptiveScale/lxdui (PYTHON) * https://github.com/turtle0x1/LxdMosaic (JS with SQL) * https://github.com/lxdware/lxd-dashboard (PHP) Quoting Incus upstream: Those more complex web interfaces will typically come with their own set of instructions on how to properly deploy them, what OS they support to run their daemon and database, how to setup the database for high-availability when in a cluster environment, how to perform backups of that data, … --- none of these seem to be good replacements of Incus UI(rebranded lxd-ui). Regards, Osamu On Sun, 2024-03-17 at 22:40 +0000, Mathias Gibbens wrote: > > Hi Osamu, > > > > Prior to the LXD/Incus hard fork, I did have an ITP to look at > > packaging lxd-ui (#1036926). I think the "proper" way to package Incus > > UI would be to have it as a new package (incus-ui), which incus > > packaging could then Recommend or Suggest. > > > > I would also be more comfortable with Incus UI it was a proper fork > > of Canonical's repository that carried the seven patches from > > zabbly/incus. As a packager, we shouldn't be taking one upstream and > > totally transforming it into something else via patches since that's > > just too much work to carry in our packaging. :) > > > > My suggestion would be to rework this bug into a RFP and/or merge > > with the prior ITP. I don't have any plans to work on this, but someone > > else might. > > > > Mathias
