The pacman packaging is broken and causing issues.

[Foxboron]

I tried figuring out how CachyOS expects the overlay repos to work but I can't tell if they are suppose to be infront of the main repos or not, regardless.

When we push new releases of pacman into the repositories your hard-forked pacman gets uninstalled. As you are incompatible changes to your version this just breaks peoples installs as the Arch Linux pacman can't parse the syncdb anymore.

Please fix this as it's causing confusion and becomes a support burden among confused staff when we do new pacman releases.

[vnepogodin]

Hi @Foxboron ,

I tried figuring out how CachyOS expects the overlay repos to work but I can't tell if they are suppose to be infront of the main repos or not, regardless.

the repos should be above archlinux repos so the packages are getting installed from our repos. all packages in cachyos-[core,extra]-[v3,v4] are built with .1 added to pkgrel.

When we push new releases of pacman into the repositories your hard-forked pacman gets uninstalled.

currently pacman 6.1.0 is not in stable repos of archlinux, we will push also 6.1.0 right after archlinux. our pacman is prepared with changes from 6.1.0

As you are incompatible changes to your version this just breaks peoples installs as the Arch Linux pacman can't parse the syncdb anymore.

there are no changes to syncdbs of our stable repos (currently), the testing repos of ours are using "new db format"(sqlite) and has other testing packages such as LLVM18(it wasnt fully rebuilt for all dependents from archlinux repos. most required and essential(+ some additional) packages was rebuilt: Rust crash on bootstrap, intel doesnt support LLVM18 yet and so the intel was disabled in Mesa). regarding(local db look into [3]) latest changes to upstream pacman with DB and package validations pacman can now reject difference if after using our pacman, pacman from archlinux was installed.

we don't maintain "compatibility" of any our repos with archlinux testing/staging repos. our repositories expect users to have our pacman installed(for easy use without issues) for quite a few reasons(mainly because of the archlinux pacman/makepkg/repo-add inability to have proper march(ISA levels) support, and quality of life improvements):

1. our pacman contains "auto detection of marches" (not accepted to the upstream pacman with comment "Users can modify their config file.") which is needed if we want to have march support without manual user intervention.
2. makepkg contains a patch to set package arch (something like rpm implemented aliasing for x86_64 and the zoo of ISA levels). so the makepkg builds packages with regular for makepkg CARCH=x86_64 but artifact will be with e.g x86_64_v3;
3. our pacman contains "installed db" patch which adds information about installed repo to local db of package when installing package via pacman or updating system(which results into installing package, but with newer or older version) to actually know from which repository N package was installed and track issues easily and not trust user. usecase for CachyOS Kernel Manager to show actual list of installed kernels including installed repository instead of matching only by name.
4. our repo-add was rewritten in Rust(we closely follow upstream repo-add changes) with such features: "new db format"(sqlite) instead of old(and stupid) compressed FS listing with tar; it supports multiple architectures in the same DB(if using new db format); it runs in parallel for all threads of the system to speed up the process significantly(resetting huge repo(like extra) takes seconds instead of 30-40 minutes); potentially eliminating bugs in upstream repo-add, for example repo-add can incorrectly handle package updates(-R flag): newer(e.g 1.5.2-5.1) package has x86_64_v3 arch and older(1.5.2-4) package has x86_64 arch.
5. our pacman contains "update notice" patch to inform all our users(which aren't watching updates on our Reddit,Forum,Discord,Telegram,Matrix) about potential update breakage or during huge rebuilds to have up to date packages with archlinux(we handle it much faster than ALHP), then to display message and block update if users wont continue with update anyway(e.g answering yes to "do you want to continue?").

although users can also use pacman from archlinux repo, but will need to take manual actions to the Architecture and such, and also without using our testing repos. most likely in future(not near) all repos will be using "new db format"

all of the patches mostly likely wont be ever accepted to upstream pacman if we follow the most "useful" one MR which got rejected.

also I think it should be obviously noted that if user is using our repos, then user should never report to archlinux and solely go to us, and if package was 100% installed from archlinux repos and still having issues(only package without its dependencies) then we advice to report to archlinux instead or if issue with archlinux repo mirrors we provide a possible fixes and if nothing helps report to archlinux. (all that if not using our testing repos, they are called testing for a reason)

we obviously want for these patches to be accepted into upstream archlinux to have proper march(ISA levels) provided out of the box(including v3/v4 repositories) on archlinux; like it's done on CachyOS

Best regards

[Foxboron]

the repos should be above archlinux repos so the packages are getting installed from our repos. all packages in cachyos-[core,extra]-[v3,v4] are built with .1 added to pkgrel.

Where is this described, because people are apparently using your repos, getting a hard-forked pacman package and then corrupting their installs when they remove the repos(?).

currently pacman 6.1.0 is not in stable repos of archlinux, we will push also 6.1.0 right after archlinux. our pacman is prepared with changes from 6.1.0

I'll move pacman after work today.

here are no changes to syncdbs of our stable repos (currently),

Sure, but I was referencing INSTALLED_DB.

our pacman contains "installed db" patch which adds information about installed repo to local db of package when installing package via pacman or updating system(which results into installing package, but with newer or older version) to actually know from which repository N package was installed and track issues easily and not trust user. usecase for CachyOS Kernel Manager to show actual list of installed kernels including installed repository instead of matching only by name.

This break things when people swap to the actual pacman package in Arch.

I think calling the package pacman-cachyos and do a conflicts/provides with pacman would be a better idea here. People clearly do not get the memo about having a hard-forked pacman package on their system.

However if you are going to move to a completely incompatible database format the problem solves itself, so it will only become an issue for users that has added the cachyos repos to their Arch install without understand the consequences. I'm partially guessing the sqlite change is going to cause a lot of confusion for those people as well.

we obviously want for these patches to be accepted into upstream archlinux to have proper march(ISA levels) provided out of the box(including v3/v4 repositories) on archlinux; like it's done on CachyOS

See the recent ports RFC.

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32

However someone needs to work on rebuild infrastructure.

[vnepogodin]

See the recent ports RFC.

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32

However someone needs to work on rebuild infrastructure.

we already have our own cachybuilder which handles all of that, should come soon automated management for "custom repos" (which are not "extra" and "core" rebuilds) via API.

API is available but only for the team with access tokens. build logs are available publicly (for example for plasma-workspace from V3 build https://builder-api.cachyos.org/api/v1/logs/x86-64-v3/plasma-workspace.log)

[Foxboron]

we already have our own cachybuilder which handles all of that, should come soon automated management for "custom repos" (which are not "extra" and "core" rebuilds) via API.

Cool, Arch doesn't.

[vnepogodin]

Sure, but I was referencing INSTALLED_DB.

This break things when people swap to the actual pacman package in Arch.

the fix for that to not validate by default as it was on 6.0.x or at least put option to disable that. there are zero issues on 6.0.x

I think calling the package pacman-cachyos and do a conflicts/provides with pacman would be a better idea here.

it would essentially will be the same

People clearly do not get the memo about having a hard-forked pacman package on their system.

they are explicitly installing it if doing manual addition of repos(but even automatic, manual instructions are there to see)

pacman comes from "cachyos" repo which is not rebuild of archlinux repos as it's a "custom repo" containing packages also for CachyOS distribution. just using cachyos-[core,extra]-[v3,v4] repos is completely fine

[vnepogodin]

Where is this described, because people are apparently using your repos, getting a hard-forked pacman package and then corrupting their installs when they remove the repos(?).

yeah we didnt have that on our wiki for repo page, available in social media(support) channels

[Foxboron]

they are explicitly installing it if doing manual addition of repos(but even automatic, manual instructions are there to see)
pacman comes from "cachyos" repo which is not rebuild of archlinux repos as it's a "custom repo" containing packages also for CachyOS distribution. just using cachyos-[core,extra]-[v3,v4] repos is completely fine

No, if they include [cachyos] ahead of [core] they are getting your pacman package without having to do anything explicit as part of a normal system update.

[vnepogodin]

they are explicitly installing it if doing manual addition of repos(but even automatic, manual instructions are there to see)
pacman comes from "cachyos" repo which is not rebuild of archlinux repos as it's a "custom repo" containing packages also for CachyOS distribution. just using cachyos-[core,extra]-[v3,v4] repos is completely fine

No, if they include [cachyos] ahead of [core] they are getting your pacman package without having to do anything explicit as part of a normal system update.

yes, correct

[Shendisx]

@Foxboron Pacman is fine even when it throws those warnings. I do not know the reason for this since i barely know how pacman works in the background.

As you can see in the attached file, i had those warnings too but they were no drawbacks and all the functions/features worked fine, they went away when today i recompiled pacman from this repo.

[ptr1337]

@Foxboron

What do you think about upstreaming the INSTALLED_DB patch to pacman or disable the validation introduced in 6.1?

We would create a PR at pacman and then we could discuss there about it. Otherwise we could also add an extra warning to our repo add script, that this will install a hard forked pacman, with some customized features/additions from our side, so the users will know about that possible feature.

We would generally very welcome to add an autodetection to pacman, but the PR we made last year, got very hardly ignored from the archlinux team, with a comment that "every user can set its own config" but this is really not a way, which we want to go and also archlinux, if they want to support different ISAs in the future.
This was also the main reason, why we started a customized pacman, since we were not able to provide a proper experience on CachyOS without these changes.

The installed db change was mainly requested from users and added from us, to avoid reports to archlinux with packages provided by us, to see, which packages are coming from archlinux repostiory (any packages and failed once) and which are coming from us.

LMK, how you would like to proceed here. Generally we would also prefer to be fully arch compatible.

[Foxboron]

What do you think about upstreaming the INSTALLED_DB patch to pacman or disable the validation introduced in 6.1?
The installed db change was mainly requested from users and added from us, to avoid reports to archlinux with packages provided by us, to see, which packages are coming from archlinux repostiory (any packages and failed once) and which are coming from us.

I personally would find it useful. I don't know if it would be accepted by the pacman devs as-is but I know the people doing distro support would appreciate the information.

We would generally very welcome to add an autodetection to pacman, but the PR we made last year, got very hardly ignored from the archlinux team, with a comment that "every user can set its own config" but this is really not a way, which we want to go and also archlinux, if they want to support different ISAs in the future.

fwiw, "the archlinux team" is misguided as the "pacman developers" is very much a small subset.

Otherwise we could also add an extra warning to our repo add script, that this will install a hard forked pacman, with some customized features/additions from our side, so the users will know about that possible feature.

I think it's important to outline. Peoples perception so far (I think) is that this is just some additional repositories.

[ptr1337]

I personally would find it useful. I don't know if it would be accepted by the pacman devs as-is but I know the people doing distro support would appreciate the information.

We will send a PR the coming days

I think it's important to outline. Peoples perception so far (I think) is that this is just some additional repositories.

We will add extra informations about that in our wiki, script as well as in the linux-cachyos readme.

[vnepogodin]

Welp repeated takes anyways. the ticket description is incorrect also (gives confusion)

[Foxboron]

@vnepogodin Yes, the initial impression was wrong so I don't think there is anything to really solve anymore.

[ptr1337]

@Foxboron

PR is posted here:
https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/150

[ptr1337]

Ill close here, since the PR got rejected and its not a packaging problem.
The information to the README is added and further informations will be also added at our wiki to fix the issue when downgrading to the default pacman.

If the feature got rejected mutliple times according Allan, there seems to be really interest for people.
Also if the above mentioned RFC will be merged/used someday, then this would be also really helpful.

But it is what it is.

[Foxboron]

Yes.

Thanks for trying at least :)