-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decouple Regolith from Debian package management #540
Comments
Hi @marc0der , I completely agree with your points. We look to address the existing coupling to Debian packaging in Regolith 2.0. We don't have much in the way of details yet on this particular item but I believe this will be in scope for the next major release. There are two issues ~ reducing the coupling between packages such that a smaller subset can be more easily ported to another Linux distro without having to "boil the ocean" and port all packages to have a working system. Second, (and more minor I believe but things always start out seeming to be minor) is to remove any existing logic that refers to dpkg, apt, or anything else specific to Debian (or Ubunutu). I would greatly appreciate your help! What package manager are you familiar with? The question on the top of my mind is, do all popular package management systems support the following features:
Regolith relies on all of these features from apt/dpkg. In fact, a primary configuration mechanism that Regolith utilizes is the package manager itself. For example, we have compositor packages and they contain package metadata such that one compositor must be installed, and all of the status indicators exist as packages that inject Much of the coupling I mention above is due to the monolithic nature of the i3 config file. As-is, any program referenced in that file becomes a hard dependency of Regolith. Another theme in 2.0 is adding a simple pre-processor that will generate the i3 config file from conf.d style partials. This allows us to break up these dependency relationships such that porting can start small, be functional, and be incrementally augmented over time. |
Oh and I happen to be an sdkman user, thanks for your efforts @marc0der ! |
Thanks for the reply @kgilmer! Sounds great as a target for Regolith 2.0, and I totally agree with your suggested approach. I've worked with several package managers in the past. I did some packaging work for some Ubuntu/Debian projects but have now been a longtime Arch (and Manjaro) user. I've also done some work with rpm, and I'm sure I'd be able to pick that up again too. I hear what you are saying about all the virtual packaging considerations, but this does lead to a very Debian-centric way of thinking about packaging. Have you ever considered a radically different approach? I'm a guy who loves automating things, so have you ever considered using a build tool/system to do the packaging for you? Consider if you had all the configuration for Regolith in a single repo (neatly modularised), and had some build tool that sat on top of this. You would be able to run different targets to produce whatever packaging you liked. You could produce a set of Debian/Ubuntu Along these lines, have you heard of jdeb? In case you haven't, it's a Java library that provides the ability to create Debian packages through an Ant task (that can easily be used from within Gradle or Maven through plugins). This is a way to get around having to use the entire Debian toolchain and be able to build packages on a CI environment. Similarly, there is an RPM builder that can be used from Maven to build Another benefit of using a build tool is the power of templates. For instance, it could be possible to use Gradle to prepare a template of the i3 config custom for a given distro. This ties in nicely with what you mentioned about the generation of the i3 config file from partials. These are all just thoughts and ideas, so take them with a pinch of salt. I'm sure you've already pondered many of these ideas too. But maybe some of these could lead to something useful that will help bring Regolith to the masses through many different Linux distros. |
Are you saying that the notion of a Virtual Package is a Debian-only concept @marc0der ? Regarding pivoting to a development model in which the Regolith DE is expressed in package-independent way and that a build system takes that as input and produces sets of packages for target Package Managers and Distributions is something I've briefly thought about. I find myself sticking to well-beaten paths simply as a matter of coping with a project of relatively large scope yet little time to devote to (being a side project). As I only know (and honestly not very well) how Debian packaging works I personally don't feel the risk is acceptably low that I would be able to produce a package abstraction and build system out of the gate that would fit well with other package systems, simply because I do not know how they differ from Debian. I have briefly looked around to see how other DEs may handle this (package/distro agnostic) but haven't found anything that is general purpose in the sense that I'd be able to use use something out of the box. I've played around with the Opensuse build system which claims to offer this but didn't find documentation that I could get to work. One approach I plan to look into once 2.0 is stable is fpm which is able to use the Debian packaging format as a source model and generate packages in other target forms. I've done a bit of testing with this and it seems to work. Another concern w/ a custom build solution is that it would require would-be contributors to learn whatever abstract packaging format that was used, vs Debian which is at least popular and well documented (assuming you're reading the right docs). And lastly, there is just a lot of long tail stuff that ends up being hard to do. By using Debian packaging I can usually find someone else having a similar problem and am able to adapt something like their strategy. But, yes, the general idea makes sense. I just don't have the time to build it myself and haven't found anything that would be suitable for Regolith that doesn't have a steep learning curve and/or large risk that it ends up just not working. Last year I devoted a lot of time to unraveling the mystery of how Ubuntu LiveCD installers are produced, and ultimately threw in the towel with nothing to show for it. I'm still somewhat recovering from that and focusing more on goals with higher impact w/ less risk. |
By no means, but it is handled a bit differently by other distributions. For instance, an Arch package in the AUR can't depend on other AUR packages (you can only specify dependencies on packages in the main repos). However, on Arch, we can have a PKGBUILD that builds multiple packages (like regolith-de does), so closer to how a build script would build artefacts. In fact, the command to build the As you can see, this is a departure from Ubuntu/Debian where a PPA's packages become part of the greater pool and allows for far more complex DAGs. The package management on Arch is purposefully simpler in keeping with their philosophy of KISS. Thus, making Ubuntu the base packaging enforces the Debian packaging onto other package management systems that aren't really compatible, or have very different ways of achieving their purposes. So my personal gut feel is that:
feels more error-prone, and prescriptive than:
Then again, I'm known to be a purist 😁 I also hear your concerns about this stuff being very time-consuming, but here I'd be happy to help by getting involved (and I'm sure others are also keen to get in). I don't think anyone expects you to do all this work by yourself or get on top of all the types of packaging systems out there. I'm also not saying that what you've done so far isn't great work, because it's awesome! I'm merely saying that the current setup does limit the scope of who the project could reach going forward. My idea of using a build tool for the packaging is exactly for the reason that you mentioned before. I don't want to know the intricacies of multiple platform packages. Others have done the work already. I would rather work on top of what they have already achieved. Gradle with the Netflix nebula ospackage plugin could save lots of time. I'm sure there are many other alternatives too. Here's my suggestion: why don't we do a small spike to test viability?
If we could initially succeed in doing a simple like-for-like, it would prove the point. This would also give us a starting point to begin iterating on. I have a deep dislike for big bang changes, so I'm not proposing anything radical here. I would do something like this in a very sensible and gradual approach. I hope you now have a clearer understanding of where I'm coming from and that I'm not thinking of any gun-slinging cowboy stuff 😄 |
Thanks for the kind words and well reasoned argument @marc0der 😄 . I think I have a clear understanding of where you're coming from and will take you up on your offer to collaborate! However I think the current work I'm doing in greatly reducing coupling across all packages needs to be stable before getting too far ahead, as the package layout change is drastic. Would you be able to do testing for AUR? Maybe some one else can cover RPM? Let's move this over to the wiki: https://github.com/regolith-linux/regolith-system/wiki/Package-Manager-Agnostic-Build-System @gardotd426 are you interested in getting involved? |
No probs and glad that you understand my intentions here.
You are so right. Decoupling package management will give us a far better foundation to work from.
Absolutely, yes. I would love to help in any way possible. |
Just dropping a note here to say that regolith-de has not seen any subsequent releases since 25 December (1.5 was the last) and has still not been released to the AUR. Also, no further updates from @gardotd426 on this. I would love to see this move forward while we don't have the newly proposed solution in place yet. What can I do to make this happen? Should we fork the regolith-de repo as an official part of regolith and start making it part of the regular releases? That would also involve publishing it to the AUR when it lands. As always, I'd be happy to get my hands dirty on this. |
Hey guys, sorry I had some equipment issues that kept me out of it for a while, but everything is now sorted and yeah Ken, I'm more than happy to get involved, this sounds like a good idea if you're able to do it. Also @marc0der, maybe contacting me on the regolith-de repo would have answered your questions, and the repository absolutely has had updates in since 12/25, actually 13 days ago was the last update, look for yourself. I don't see a reason to do GitHub "Releases" for an Arch Linux PKGBUILD, that seems nonsensical. But the repo has been getting updated as needed. And at this stage, everything is to the point where the only things that will be changing are the PKGBUILD and then maybe little patches here and there to fix Arch/Ubuntu differences, but they're rare and I've been able to remove most of them by now. So yeah, weekly/bi-weekly updates to package version numbers will be the only thing changing from here on out. A user kindly put together a python script to help me automatically update the PKGBUILD with new .deb package versions, so I don't have to manually update it, because trying to track 40-something packages for version changes and then individually change them is insanely tedious. I'm looking to set up something that can automatically run the script at a set time (probably weekly) and notify me when there's updates so I can merge the PKGBUILD files and push the update to the repo. So I guess I anticipate a move to the AUR in the next week, as if it's this stable and only needs to be changed to track package versions (for the most part, unless something breaks where I fix it before pushing the update), then why not have it in the AUR? The main reason I've waited is for more testing, as 3-4 people isn't enough for a desktop environment for me to feel comfortable with stability, but the past few weeks I've had more and more testers, to where I'm around 20 at this point, and I feel comfortable pushing to the AUR. But yes, a distro-agnostic build system would be a dream come true for me at this point, and am happy to help however I can. |
@gardotd426 Well, this is fantastic news, and I'm thrilled to hear that regolith-de is still alive and kicking! I'm also happy to join your testers and will certainly engage with your regolith-de repo going forward. It would be super nice to have some tags corresponding to the official regolith releases though, no need for full-blown Github releases. I think we are currently standing at 1.5.3, and it would be good to track this in your repo too. Also, great to hear that you are about to go live to the AUR! Have you considered using simple Github actions to automate this process? I'm happy to help you get this up and running. But let's move over to the regolith-de repo for further discussion. |
Release is on 1.5, I see nothing on Regolith's website about 1.5.3, and I've had my PKGBUILD versioned 1.5 for weeks (since Regolith moved to 1.5 from 1.4.3 or 1.4.1 or whatever). I see no point in tagging the github repo according to Regolith release version numbers, the only real important thing is to have the Arch PKGBUILD match up with the Regolith version its taken from, and it already does that. This is intended to be an AUR package. Furthermore there's no real way to even automate versioning and I don't plan on constantly checking the Regolith home page to find out what the latest release one the "Release" PPA is. Do you? I was hoping there was a package included such as But yeah, I'd written a script to handle the automatic updating of the PKGBUILD and include an updating of the pkgver, but there's no package version that corresponds so there's no easy way to do this, so for now I'm just tracking 1.5 as the documentation says. But yeah feel free to open an issue on my repo if you want to discuss anything about |
Hey guys 😄 . I try and keep the github release tags up to date here: https://github.com/regolith-linux/regolith-desktop/releases You can follow the @RegolithL twitter account or the regolith mailing list to get announcements for releases, if you'd like.
Well, the DE is a set of many packages. For the full ISO, a package Also, a bit of an update from my end, the 2.0 work is coming along well. My focus has been on reducing the package graph as much as possible to aid in porting as well as just enabling users to have light setups. Regolith 2.0 can now run on i3 or i3-gaps, and the package manager will handle all the compatibily details if a user switches between them. Also, it's running on Debian in 281Mb cold start. There is still some work remaining on the desktop metapackages but overall I think the scheme is in good shape as a PoC. I will add some documentation to the wiki and call for comments from users in the next week or so regarding the general design. |
So, about the build system...is anyone of a general purpose package model in a modern format? |
@kgilmer Awesome news about the 2.0 work, It sounds like you are making great progress. Also, thanks for clarifying about the versioning. This makes perfect sense. We can pick this discussion up again on the regolith-de repo. So about the build system. I have been giving this some more thought and have some ideas about how we can do this in the simplest possible way. My initial thoughts about using Gradle and plugins have changed somewhat. Instead, I'm thinking of using something more native. I thought of using Anyway, these are just thoughts for now, but I will report back when I have something more solid up and running over your 2.0 work. |
Hey @kgilmer, someone just made me aware that you aren't packaging rofication on launchpad the same way you have it on the regolith-roficiation repo. They simply pointed out that you aren't including the This actually means that I have to wait until it's fixed to put it live on the AUR, or just remove rofication and use dunst or some other notification manager. The problem is, AUR packages can't (at least are absolutely not supposed to) require user intervention, but the way things are right now, rofication won't work unless the user pulls the setup.py script from your repo and runs it. So we're at a bit of an impasse. I can still leave up my PKGBUILD repository, but I can't put it on the AUR until this is sorted. |
Hmm, yes looking at the output I'm guessing this is a case where a package agnostic build approach would shine. I'm guessing your porting is constrained by what your native packaging system needs and what the debian packages provide.
This file is now shipped in the binary package |
Well, that's the thing. Without running the It's not anything like
Ah cool, I noticed you'd added a couple new modules lately, I'll go ahead and add that to the i3xrocks package then. I'll let you know once I figure it out, but I already have a couple ideas. Thanks for the guidance |
My apologies if I came across defensive or weird there, it wasn't intentional. Somehow I have a very low patience threshold when dealing w/ python issues in general. I have no good reason, just a personality quirk I guess. In any case, thanks for your clarifications. Yes, it's true that despite the deb package simply saying it's shipping the python file, actually quite a bit more comes along for the ride: $ dpkg -c ~/Downloads/regolith-rofication_1.3.1-1_amd64.deb
drwxr-xr-x root/root 0 2020-12-27 11:27 ./
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/bin/
-rwxr-xr-x root/root 417 2020-12-27 11:27 ./usr/bin/rofication-daemon
-rwxr-xr-x root/root 169 2020-12-27 11:27 ./usr/bin/rofication-gui
-rwxr-xr-x root/root 1157 2020-12-27 11:27 ./usr/bin/rofication-status
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/lib/
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/lib/python3/
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/lib/python3/dist-packages/
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/
-rw-r--r-- root/root 414 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/__init__.py
-rw-r--r-- root/root 1536 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_client.py
-rw-r--r-- root/root 3345 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_dbus.py
-rw-r--r-- root/root 3665 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_gui.py
-rw-r--r-- root/root 214 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_metadata.py
-rw-r--r-- root/root 1260 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_notification.py
-rw-r--r-- root/root 3908 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_queue.py
-rw-r--r-- root/root 2893 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_server.py
-rw-r--r-- root/root 297 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_static.py
-rw-r--r-- root/root 1092 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/_util.py
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/resources/
-rw-r--r-- root/root 163 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/resources/__init__.py
-rw-r--r-- root/root 1042 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication/resources/_static.py
-rw-r--r-- root/root 533 2020-12-27 11:27 ./usr/lib/python3/dist-packages/rofication-1.2.2.egg-info
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/share/
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/share/doc/
drwxr-xr-x root/root 0 2020-12-27 11:27 ./usr/share/doc/regolith-rofication/
-rw-r--r-- root/root 1121 2020-12-27 11:27 ./usr/share/doc/regolith-rofication/changelog.Debian.gz
-rw-r--r-- root/root 1231 2020-12-27 11:27 ./usr/share/doc/regolith-rofication/copyright Again, I can't say if this should be sufficient for a working Python module, but perhaps this provides some help. I do know that a python-specifc build system is used to generate the package, and this is integrated w/ the debian packaging. I'm not sure but maybe this is doing some magic that does whatever If you come up w/ anything specific you'd like to try, I'm more that happy to build some test packages w code changes, just LMK 😄 |
Oh no worries man, it's all good. But yeah I know about the other files aside from what's in /usr/bin, I install the whole package, I'm not just pulling deb files. There's a script in the PKGBUILD like this:
And then for each .deb, I just have to run Also if necessary I could potentially just break regolith-rofication into its own separate PKGBUILD instead of being part of a meta-package, and instead of using the deb, just clone the repo, because I can clone the repo and build and install from within the PKGBUILD just fine, it's just, it's hard to explain but the way PKGBUILDs work for meta-packages, defining one git repo for one package can mess all the rest up, but honestly that's not even a remotely difficult thing to do, it would literally just be mostly a copy and paste thing, and I'd just have two PKGBUILD files. But yeah, I think debhelper-python is what's doing it for you on the Ubuntu side, which makes a ton of sense. No worries, I have like 5 different solutions, I'm just researching which one would be the "best" one, or at least the one I'm likely to get the least complaints about lol. |
I got it figured out. I just had to dig deep into some Arch documentation about including Python packages in PKGBUILDs, because the normal procedure/recommendation is to use PyPi/Pip, but they do have procedures for PKGBUILDs for Python packages that aren't available there. I just tested it and it works great, I'll be updating the PKGBUILD in a few. |
I have started working working on something similar to this in order to support Debian and Ubuntu. It's nothing fancy, just some bash code and a JSON document that describes all packages necessary to build the Regolith DE. It's somewhat simplified at the moment as it's only building a subset. There is a repo that contains the scripts (mainly just a convention): https://github.com/regolith-linux/pkgrepo-lib and then "child" repos (currently only https://github.com/regolith-linux/pkgrepo-ubuntu-focal) that include the scripts, add their own specific package models (Debian generally needs more than Ubuntu) and any custom scripts. Rather than just straight docker, each "child" repo uses gh actions to essentially do the same thing ~ create a container and do some work. The results are committed back to the source repo in my current case, as I'm able to use the Github Pages feature to host the repositories. Unsure if this is how things will be for production but works well enough for me now. I plan to use this approach to completely automate generation of Ubuntu Bionic, Focal, Groovy and Debian Buster, Bullseye package repos. What do you think? Is there anything about the system I describe here that would be prohibitive to non Debian based systems? |
FYI I've been adding issues to give a little more insight as to what I'm doing: https://github.com/regolith-linux/pkgrepo-lib/issues |
Hi @kgilmer! Firstly, a big apology that I haven't replied to you sooner. I've been a bit swamped with work the last while, so I haven't had much chance to look at this stuff again. That said, I hope to have a closer look over the weekend. Happy to have a play and give some feedback regarding this. |
I'm suffering from a bad case of day-job myself recently, no worries @marc0der . Come back to this when you have the time and interest 😄 |
Things have moved around a bit now that the names matter..
|
Hey all, any updates on moving this forward since March? I'm already testing regolith-de on arch, @gardotd426, and it's working totally great. |
I'd like to chime in as well here, I'm looking at porting regolith to gentoo, and the first hurdle from my perspective is determining how and when releases are cut. I'm under the impression that @gardotd426 has been unpacking .deb files from the PPA but that doesn't really work for me on a source based distribution. I've had a look around and while the package model in https://github.com/regolith-linux/package-repo is great for determining where I can grab sources and what sources I need, it doesn't really help me with versioning, nor is there a consistent source of truth for what source files were used to build which version. Is there any way to add a |
Yeah I struggled for quite a while with trying to figure out how exactly to version stuff (especially since with metapackages in the AUR, there can only be one package version), before I moved most of the non-Regolith-specific packages over to Arch repo packages (like i3-gaps, picom, etc), so my PKGBUILD mostly just provides regolith-specific stuff, so I landed on using the current Regolith version. So right now it's 1.6. But yeah there seems to be little rhyme or reason on the versioning on source repos, I'm in the process now of moving whatever I can over to being built from source instead of just extracting .debs. @a-crate I got your email, I'll email you back shortly answering some of your questions |
Hi @a-crate , that's exciting news. I learned a lot from running Gentoo for years and years. It would be amazing to have Regolith run there as well. Preamble: Only the
Things are a bit weird right now due to the transition from Regolith 1.x to 2. This major version bump constitutes the change to clean things up and do things in simpler ways while breaking with the old, launchpad.net-based build/repo model. The 2.x build stuff in part is to make it easier for efforts such as yours to port the packages to other distributions. 2.0 is still in development and so if there are ways that this approach can be improved this is certainly the time to make the right changes. As such, you are not finding any versioning stuff because there has yet to be a version of Regolith 2.x. The general workflow for how packages go from source in git repos to installed packages on user's systems is described here. In summary, the "version" of Regolith 2.x is the set of git URLs and branch/tag names specified in the root package model + any distro specific overlays (ex).
Again, since we are before an explicit version, this information does not yet exist. My thinking here is that rather than having a single package model + overlays, rather these will be maintained per distro. So the file
Yes the current field
Yes, Hopefully that answers your questions to some degree @a-crate . FWIW if you were to provide a GitHub action like this for your target distro, all of the versioning would generally be handled and you'd just* need need to build and stage packages for your target distro. EG when Regolith 2.0 had it's first release, your action would be called just like the Debian and Ubuntu actions. (*: of course it's never that simple and I'm sure there are things I'm entirely unaware of that need to be solved.) |
More details here (I just refreshed this page): https://github.com/regolith-linux/regolith-system/wiki/Package-Build-Automation |
Yeah, this along the lines of what I told @a-crate in my email. It is a bit of an awkward situation right now. Personally for the Arch side of things, I've just been sticking with "Release" debs while slowly transitioning some of the packages over to building from source (and I'm using repo packages for all non-Regolith dependencies, like i3-gaps, etc). Meanwhile I have a private alpha that I'm testing using some stuff from package-repo in preparation for the move to 2.0. I'm interested to see where 2.0 goes. I've noticed though that one thing preventing from a full move over to source builds are that quite a few packages are missing from Is there any more you can tell me about the move to ilia and away from Rofi? I notice that the alpha still uses rofi. I've got ilia built and working on my alpha build, but I don't have it integrated into the system or anything (it's still using rofi). |
I'll add that I just looked over the Package Manager Agnostic Build System goals and it sounds great. Really all I would need for Arch is a way to build each project from source. The beauty of pacman/makepkg is that if I can build the project from source I can create a pacman package easily. Obviously for stuff like the regolith-desktop-config with the config files don't need buildling, I can just pull them in, patch them as needed and package them. Same would go for any styles and icon themes, and anything script based. Currently in the AUR package I'm building regolith-rofication, i3xrocks, and remontoire from source. Seeing that you've added ayu-theme to Submodules would be great. Right now if I want to use package-repo, I have to trawl through the available packages in With submodules where each submodule is a repo for a regolith package (or group of packages), I could easily set it up to clone it, build each in order, and package. |
Ah, okay. I see. Right now I'm moving forward with just creating ebuilds from the most recent source tarballs from launchpad for 1.6, is this generally stable for now? Will you be moving away from launchpad entirely with 2.0, or will it just become a place to host built packages for debian+ubuntu, with other distros rolling their own? I'm personally not a fan of submodules, as I need to sandbox every build to make my package manager happy, but they don't interfere at all as long as package-model.json exists. I will wait until I've figured out manual packaging before automating anything but this has been very helpful, thank you. |
You can still check out individual submodules as repositories though, right? Like if you have a repo with say 4 submodules, sub-a, sub-b, sub-c, and sub-d, you can also just clone sub-a, sub-b, sub-c, and sub-d separately at the same tag as the parent repo provides. Here's an example of that, Tk-Glitch's PKGBUILDs repo is full of a bunch of submodules for different PKGBUILD projects. But I don't use that PKGBUILDs repo, I just clone the ones I want to use individually. Does that not work for what you're talking about? I mean I guess if you could just use package-model.json it doesn't really matter, but I figure it'd be way easier to do it the checkout-submodules-individually way. |
gardotd426:
I haven't gotten around to it yet. In a bit more detail: the Regolith Look "system" in Regolith 1.x ended up not being flexible enough for some use cases, like making it easy to use a different bar or launcher and have it "just work". 2.0 makes breaking changes here in an effort to bridge the gap. I'm also thinking of doing less here in terms of prepackaged themes, from an "official regolith" prespective. In that line, the 1.x themes that do carry over will likely go into an If you have particular looks (or other functionality) that you want to see in 2.0, please LMK.
Development continues :). At this point all Rofi functionality needed by Regolith has been implemented except for window switching and file search. I hope to complete window switching today. Once the core functionality works I'll considered it in a good enough state for an alpha release. At that point I'll probably spend some time in
Fantastic! Thanks for the feedback
Well that's what the scripts in this github action do. If you come up with something similar for Arch you would only need to implement "building and publishing a given package". To be clear, we would add a github workflow that calls your action to generate packages. If you look at the shell script associated with the action, you'll see places where (Ideally the build infra would not be so tightly coupled to github, but as a matter of time I think it's the best compromise and only hope that the carpet isn't pulled from under our feet.) |
a-crate:
This is very stable, as no future updates to 1.x are planned.
This question is still open. Launchpad has this special "superpower". There is a command on all Ubuntu's ( Regarding submodules, I agree that @gardotd426 's proposal is good in that it is simple and consistent with git. However in practice I've had a trouble with submodules in past projects and prefer to avoid them as a keystone to rest other work upon. |
In case it's preferred, I've created a slack channel "distro" just now. If anyone would prefer that format for discussion rather than this issue. |
Yes but it's functionally the same as cloning the repository directly for me. Like, for example, if I were to package the modules in that repository for gentoo, I would need a package for each submodule. I could I'm not opposed to them at all, I don't want to seem like I'm trying to dissuade from submodules. I would just prefer that they aren't the only method.
I will jump in there if I have any issues, packaging is going relatively smoothly for now. |
FYI the package builder now supports stages. To reduce unnecessary variance, the stages in Regolith 2 will adopt the same names as Debian. Before: Stages are implemented without any new concepts to the build system. The stage just becomes another dimension of the build matrix, which is now: |
That sounds pretty awesome, actually. About the themes and styles you mentioned here:
My thinking is just that, for my port, I want it to be the whole regolith experience. That requires some editorializing on my part, but as far as the styles go, I think I should provide all styles that regolith supports. Ayu, Ayu-Dark, Ayu-Mirage, Cahuella, Dracula, Gruvbox, Lascaille, Midnight, Nord, Pop-OS, Solarized-Dark, Solarized-Light, and Ubuntu. SOME of those looks' theme and icon theme components (as in the stuff that goes in Like, I can get all the components myself, but the theme files, I would like a repository for. Is that doable?* * I know that a lot of things are changing in 2.0 and you might not even use some of those themes and might add new ones, but I"m saying whatever themes/styles you do provide /etc/regolith/styles/ files for, that's what I'd like a repo for, if that makes sehse. |
How often will release be updated compared to testing/stable? Is release something that will only change on the timescale of debian/ubuntu releases with testing updating in between, or is it quicker than that? I've not looked into the automation at all yet, I know for gentoo I really just want a system to make a tarball of the source and put it in a git repo with a tag for the version. That sounds relatively simple, I assume it's capable of that. |
Sure, that shouldn't be a problem. FYI in Regolith 2 the styles files are broken into two categories: style definitions (colors, fonts, etc.) and application bindings (specific Xres files for a particular user program, scripts, etc.). For the former, I only have one example at the moment: Other looks will likely be stand-alone packages or possibly a
Yes, on the order of several months to years. We've been roughly tracking Ubuntu's release cadence and doesn't seem like anything else is going to replace that in the short term.
Due to the time costs of testing, releases will not be patched. If a serious problem is found, we would do a point release, or I guess this is what you mean by a patch perhaps. Regarding problems that may impact distros other than Ubuntu, I would like to do my best to provide support regardless of the distro until/if it becomes too time costly for me personally. For now at least any issue that comes up from Arch, Gentoo, or others will be treated with the same gravity as Ubuntu or Debian bugs. The specific example you bring up is a little odd because in this case we're fully replacing one program for another, and we're in the middle of a major version bump.
This would be an add-on to the build system for the |
Something like a
And I'm sure you'd be willing to accept PRs for stuff like that, as in stuff that affects other distros, right? So if something came up that affected gentoo, @a-crate could file a PR to fix it? |
Oh, sure. I don't think it would be fair to expect you to spend tons of time working on a side project. And I figured that any patches need for gentoo issues would be coming from me anyway, if for no other reason than I'm the one running it. I figured you were likely targeting the same timescale as debian & co. and wanted to be sure fixes for other distros could still make their way to release if necessary, since the timescale for us is very different. |
Yes of course. As contributors, you're able to create PRs directly against the repos, as well as review and merge them. |
I took another stab at providing documentation for extending the package builder for other types: https://github.com/regolith-linux/package-repo/blob/master/CONTRIBUTING.md |
To keep this issue up to date, the build system underwent another rewrite and now lives here: https://github.com/regolith-linux/voulage I have yet to implement one but the automation (bash based) allows for extension via sourcing a script that would implement well-known functions (an implicit interface): https://github.com/regolith-linux/voulage/blob/main/.github/scripts/ext-template.sh |
Excellent. I'll take a look here in a bit. Thanks for the update. I'm on
the Slack group but I have been bad about keeping slack open (I don't use
it other than for this).
…On Sat, Jan 29, 2022, 2:21 PM Ken Gilmer ***@***.***> wrote:
To keep this issue up to date, the build system underwent another rewrite
and now lives here: https://github.com/regolith-linux/voulage
I have yet to implement one but the automation (bash based) allows for
extension via sourcing a script that would implement well-known functions
(an implicit interface):
https://github.com/regolith-linux/voulage/blob/main/.github/scripts/ext-template.sh
—
Reply to this email directly, view it on GitHub
<#540 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AM5Y336JGS3KYPPSVNVY2WDUYQ44TANCNFSM4WMQ6ANA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Is your feature request related to a problem? Please describe.
I love using Regolith, but like many other users, do not feel the same way about Ubuntu. At the moment, Regolith is very tightly coupled to the Debian package management, which makes porting Regolith to other distributions very difficult and cumbersome.
Describe the solution you'd like
It would be fantastic if all Regolith configuration lived in a separate repo, decoupled from all the Debian packaging config. This would allow other spins (such as an Arch or Fedora spin) to be created from the centralised configuration. The current Arch (and Manjaro) packages rely on transforming the Debian artefacts, which works but is an error-prone and labour intensive process.
Describe alternatives you've considered
I've been using the regolith-de package provided by @gardotd426 (which is a great first attempt to get this working, thank you!), but this package tends to fall behind and not on the Arch AUR. Even though this works in the short term, it is not an optimal solution and will require lots of effort to be maintained in the future.
Proposed solution
Having a separate repo for the Regolith configuration could allow this project to have multiple automated builds that produce releases for all popular Linux distros. This would definitely further the reach of this fantastic project and help in adoption by many tiling window manager fans like myself who do not want to be tied to Ubuntu.
I am willing to get involved in such a project and would love to know your thoughts around such a proposal. It certainly means quite a bit of work, but could potentially open up many new avenues and bring lots of growth for this project in the future.
The text was updated successfully, but these errors were encountered: