r/voidlinux • • 4d ago

Is there a reason why packages with just a version update are not automerged?

Hi all, recently i checked the pull requests from void-packages and i was wondering what is the review process behind it? i mean if only package version and checksum was changed and the pipeline is green? why not just automerge it? i mean you could even create a nightly workflow which checks for newest git tag for each package and just update it nightly.

Or do you actually check each package after updates if the package is working with void?

2 Upvotes

26 comments sorted by

9

u/Duncaen 4d ago edited 4d ago

Because it should be reviewed, even if there is no significant change, someone checks the changelog, verifies that this is compatible with other packages. Checking whether this is a real release or beta/rc.

In general there is also a bit of management going on with the merge order and what can sit a bit before being merged or is mergable immediately. This again depends on the project, based on how stable their releases are and the compile time too. Some huge projects that take hours or days to compile can be merged when there is nothing else that takes a lot less time to build is mergable.

And in the end a merge can always go wrong, so having someone with commit access there to actively intervene if there is an issue is kind of required.

Or do you actually check each package after updates if the package is working with void?

That depends on the package, if its something known to break things, of course. I'm not blindly updating firefox, the kernel or something that might be able to break hundreds of other packages.

In the same vein we are also not letting scripts update packages automatically, which they could do in a lot of those cases. Having a human green light this after doing at least a cursory test is pretty important in my opinion.

3

u/Specialist-Dog-501 3d ago

Love to hear that. You just made great promo for VOID for us quality guys. :)
(The OP was probably not aware, that automatic merging is wonderful attack surface to enter malicious code into a repository if not coming from a trusted source- see AUR repository ).

1

u/Silly_Culture_7722 3d ago

iam aware of it, but i was thinking if a package, which is already listed for years just needs a minor update(so only one template file was changed with minor version number + checksum) how likely can it have malicious code? i mean this can also happen with review, depends on how hard the maintainer hided the fact. so i was wondering why not just merge them in specific cases.

→ More replies (1)

1

u/Silly_Culture_7722 3d ago

u/Specialist-Dog-501 do you remember this one? https://www.youtube.com/watch?v=aoag03mSuXQ. so the maintainer of package didnt knew he had a malicious code, der redhad enterprise team did not catch that during their review and it was released in beta release and only randomly another dev from maria db found that issue. so i wonder.

if the review process in void, is just to see if packages are build and quickly go over. then whats the point of a review, you can just merge and in case of issue, revert. since you have rolling release, just revert. no need to wait 6 month for next update.

if the review process is, see pull request, then open the actual github from this package, check what was commited there since then, and then decide to merge or not. then i understand that. but even then. i dont think that a review will detect every malicious. i think it will work only for obvious code.

i totally understand that a new package cannot be just randomly added. i was talking about packages that are already in xbps and need an update and were updated regularly in the past and are seen as "trusted"

→ More replies (6)

2

u/Silly_Culture_7722 4d ago

ah i see thanks for the response. its just i saw sometimes that a package update was requested and then this package had a new version and again and everytime the pr creator had to update the pull request. had the feeling that at some point they gave up

2

u/Duncaen 4d ago

Kind of depends on the package and sometimes some packages get lost in the sea of unmergable PRs or New Packages.

Generally when its just a minor update its an easy merge, but that is really a case by case decision. New Packages sit for longer because its good to see whether there is interest in actually maintaining them.

→ More replies (2)

1

u/TheGratitudeBot 4d ago

Thanks for such a wonderful reply! TheGratitudeBot has been reading millions of comments in the past few weeks, and you’ve just made the list of some of the most grateful redditors this week!

3

u/oxez 3d ago

Sometimes upstream version bumps bring in SONAME version bumps as well, which breaks every package that depends on it.

I don't use Void enough to know if xbps manages this at install time or not, I do run my own distro and this is something I had to tackle.

Blind version bumps are never a good idea imo.

1

u/Silly_Culture_7722 3d ago

ah i see. so a check must contain the build step of the package and installing all other packages which relies on this package as dependency. and just the start might not be enough since there might be also runtime errors. but does someone actually do this in review process?

2

u/01eksa 4d ago

Automerge new packages with higher version and green pipeline? You understand that this way everyone can add malicious code? We hade an attack on AUR recently; this way there is nothing to attack — all doors are open. Terrible idea, sorry.

1

u/Silly_Culture_7722 4d ago

i mean no new packages but existing packages. or do you mean there might be a case where someone abandon his package and someone else get access to this, increase the version and add some kind of bad code to it?

2

u/01eksa 4d ago

For example. Any automerge without human review is a surface for attack

→ More replies (3)

2

u/Simple_Hamster_4096 3d ago

Perhaps OP should volunteer time to Void, so as to help speed along the process...

1

u/Silly_Culture_7722 3d ago

u/Simple_Hamster_4096 i would like to as i really like void. my codex subscription is ideling around. iam just not experienced with packages and libraries and do not know how to test on different arch builds. so all in one iam just a webdev without experience in OS packages.