Comments (11)
rua’s support for maintaining local patches looks great. The approach of keeping a local git branch and merging from AUR with git is unique as far as I know.
Yay and aurutils support this as well at least.
I would discourage from adding ABS support for the fear of feature creep. Plus there's already a great tool called asp
for using the abs.
from rua.
Thanks, I will look some more into yay and aurutils.
asp
looks like it could be good building block, but does not itself automate the scenario of downloading binary updates from official repository except when local patches are configured, in which case rebuild from source with patches reapplies.
Regarding feature creep, that’s totally understandable. It appears to be a design decision of this project to only deal with AUR.
from rua.
@SimonSapin glad you like the local patch application technique! Works pretty stable indeed. I don't know how/if other clients support that. None seem to advertise this feature. I just tried to use yay
, but I couldn't find a way to patch a local package. Maybe you can do it manually if you drop to shell though.
If ABS can be added as a simple self-contained action, it could be considered I think. But it's better to lay out the whole plan before starting to build it, to verify that it indeed suits well. Please do in that order if you'll attempt it.
One big question so far:
- how to deal with split packages? For example,
bubblewrap
is a split pkgbase. It has one split name that is identical to pkgbase name, thus you can easily access its git repo: https://git.archlinux.org/svntogit/packages.git/log/?h=packages/bubblewrap but you cannot trivially get the same git repo if you look forbubblewrap-suid
: https://git.archlinux.org/svntogit/packages.git/log/?h=packages/bubblewrap-suid This is one of the tricky parts with split packages
Also note that upgrades of ABS and other ABS-aware changes will never make it into the client I think. Only building of one specific package, if it's self-contained and integrates well.
from rua.
So one alternative is to assume that the user is totally aware of split packages and won't have problems with them. Then it'd work like:
rua buildabs pkgbase
- use the already exisiting review capabilities of RUA, with only a different
git
address - internally invoke
rua builddir
, which would build the package, and review its contents after building
This way, almost 100% of the functionality is already there, so the maintenance cost and complexity seems almost unchanged. Did I miss anything? Is the assumption "pkgbase = what the user wants" valid?
from rua.
Does AUR have any split packages? How does rau deal with those?
from rua.
@SimonSapin it uses AUR HTTP interface: https://aur.archlinux.org/rpc
I gave the idea more thought, I think it'd be OK to only support building "pkgbase" as a first step. It'll be the user's responsibility to find the correct name then.
If you'd be willing to write an MR that introduces this subcommand and basically reuses already existing functionality (with a different git address), I think it can be merged. I don't see any problems with it, at least.
from rua.
Not sure what's so hard about getting the pkgbase of a pkgname. Just query alpm.
from rua.
@Morganamilo indeed, thanks for the hint!
from rua.
@SimonSapin would you be willing to work on this? It's fine if you don't, just better to know.
from rua.
I was hoping for a (set of) tool(s) that would automate the entire workflow of updating ABS packages with local patches: see (through pacman -Sy
or similar) that a newer binary package is similar, skip it and get its PKGBUILD
instead, merge with local changes, rebuild, and install.
Also note that upgrades of ABS and other ABS-aware changes will never make it into the client I think. Only building of one specific package, if it's self-contained and integrates well.
Limiting rua’s scope is totally understandable. But that feature is only a marginal improvement over the status quo while still being non-trivial to implement, so I likely won’t. Closing this issue as a result, thanks all for the discussion.
The (less automated) workflow I settled on is like this:
When first patching a new system package, use asp checkout
to get a git repo of its PKGBUILD
and associated files. Make changes in a local branch, then build and install manually with makepkg -i -c
. In /etc/pacman.conf
, add that package to IgnorePkg
so that pacman prints a warning when a newer version is available, and does not silently "erase" the local patch with it. When that happens, manually use git pull
to update PKGBUILD
and rebuild.
It’s a lot more steps, but I have patches for few enough packages that get updated infrequently enough that it’s still the lowest-effort I’ve found.
from rua.
I'll re-open to think about it a bit more (currently on a vacation).
from rua.
Related Issues (20)
- Weird failure to build lib32-lzo HOT 2
- Unattended option
- I am getting the famous `exists in filesystem` error HOT 6
- Better package naming? HOT 1
- Give upgrade -y to process without confirmation? HOT 1
- Cover -git package when doing upgrade and add update out of date package? HOT 1
- python-blis 0.7.7-1 error when building HOT 3
- Rua will not attempt to build for alternate architectures if a package is marked x86_64 only
- Allow to pass in flags to makepkg command
- Allow more fine grained controls in diff HOT 9
- Further improve file diff when upgrading package
- `rua install` doesn't work under systemd-homed user HOT 4
- Dependencies not resolved correctly for split packages
- Segfaults on search HOT 7
- Sandboxing hardening suggestions (`/mnt`, `/media`, PKGBUILD directory) HOT 2
- Decrease compilation time for updated packages HOT 1
- Patching PKGBUILD/.SRCINFO should immediately impact the dependency tree HOT 8
- RUSTSEC-2021-0139: ansi_term is Unmaintained HOT 1
- [Feature request] Add the ability to use a separate pacman.conf HOT 4
- Workflow idea: frequent builds in non-interactive throw-away VMs. Review and approve process is decoupled and allows for zero build time
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rua.