ALHP/ALHP.GO
6
42
Fork 9
Code Issues 25 Pull Requests Projects Releases Wiki Activity

[Documentation] retain original repository order #255

New Issue
Closed
opened 2024-07-28 16:39:11 +02:00 by merrkry · 13 comments
merrkry commented 2024-07-28 16:39:11 +02:00
Copy Link

Because of the way pacman searching packages, when installing initramfs on a new system, booster in [extra-x86-64-v*] will be used instead of mkinitcpio in [core], which is Arch's current default options.

To fix the problem, the following order in pacman.conf may be more suitable:

[core-x86-64-v3]
Include = /etc/pacman.d/alhp-mirrorlist

[core]
Include = /etc/pacman.d/mirrorlist

[extra-x86-64-v3]
Include = /etc/pacman.d/alhp-mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist
Because of the way pacman searching packages, when installing `initramfs` on a new system, `booster` in `[extra-x86-64-v*]` will be used instead of `mkinitcpio` in `[core]`, which is Arch's current default options. To fix the problem, the following order in `pacman.conf` may be more suitable: ``` [core-x86-64-v3] Include = /etc/pacman.d/alhp-mirrorlist [core] Include = /etc/pacman.d/mirrorlist [extra-x86-64-v3] Include = /etc/pacman.d/alhp-mirrorlist [extra] Include = /etc/pacman.d/mirrorlist ```
👍 1
anonfunc commented 2024-07-28 21:58:45 +02:00
Owner
Copy Link

Yes, I also noticed that the current order could be optimised. We could also include a note that lower repo levels can be used as fallback repos if a package on a higher level fails. For example:

[core-x86-64-v3]
Include = /etc/pacman.d/alhp-mirrorlist

[core-x86-64-v2]
Include = /etc/pacman.d/alhp-mirrorlist

[core]
Include = /etc/pacman.d/mirrorlist

[extra-x86-64-v3]
Include = /etc/pacman.d/alhp-mirrorlist

[extra-x86-64-v2]
Include = /etc/pacman.d/alhp-mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

That way, if a package fails on v3, but builds fine on v2, you would still get the v2 package instead of vanilla Arch. The only drawback would be that if that package is later available on v3, pacman would not automatically update to v3 until a new version is released.

Yes, I also noticed that the current order could be optimised. We could also include a note that lower repo levels can be used as fallback repos if a package on a higher level fails. For example: ``` [core-x86-64-v3] Include = /etc/pacman.d/alhp-mirrorlist [core-x86-64-v2] Include = /etc/pacman.d/alhp-mirrorlist [core] Include = /etc/pacman.d/mirrorlist [extra-x86-64-v3] Include = /etc/pacman.d/alhp-mirrorlist [extra-x86-64-v2] Include = /etc/pacman.d/alhp-mirrorlist [extra] Include = /etc/pacman.d/mirrorlist ``` That way, if a package fails on v3, but builds fine on v2, you would still get the v2 package instead of vanilla Arch. The only drawback would be that if that package is later available on v3, pacman would not automatically update to v3 until a new version is released.
anonfunc added the
enhancement
 label 2024-07-28 22:12:42 +02:00
Stebalien commented 2024-08-07 01:09:00 +02:00
Copy Link

That way, if a package fails on v3, but builds fine on v2, you would still get the v2 package instead of vanilla Arch. The only drawback would be that if that package is later available on v3, pacman would not automatically update to v3 until a new version is released.

Any reason not to use x.y, pkgrel versions where x is the upstream pkgrel and y is the architecture version?

> That way, if a package fails on v3, but builds fine on v2, you would still get the v2 package instead of vanilla Arch. The only drawback would be that if that package is later available on v3, pacman would not automatically update to v3 until a new version is released. Any reason not to use `x.y`, pkgrel versions where `x` is the upstream `pkgrel` and `y` is the architecture version?
anonfunc commented 2024-08-07 09:41:17 +02:00
Owner
Copy Link

I'm not quite following. We already do this, right? How is that related to the repo ordering?

I'm not quite following. We already do this, right? How is that related to the repo ordering?
BS86 commented 2024-08-07 16:24:52 +02:00
Copy Link

I guess he wants to say, instead of setting .1 for each rebuild, set .2 for V2, .3 for v3 and .4 for v4.
That way, the highest feature level will always be the one that gets used, no matter if it only gets available in a further rebuild.

Doing a bugfix rebuild, that in the past got the .2 would need to get .5, .6 and .7 (or .12, .13, .14)

I guess he wants to say, instead of setting .1 for each rebuild, set .2 for V2, .3 for v3 and .4 for v4. That way, the highest feature level will always be the one that gets used, no matter if it only gets available in a further rebuild. Doing a bugfix rebuild, that in the past got the .2 would need to get .5, .6 and .7 (or .12, .13, .14)
Stebalien commented 2024-08-07 16:55:10 +02:00
Copy Link

Yeah, that's what I'm suggesting. But I didn't realize these were used for bug fixes as well.

Unfortunately, x.y.z doesn't appear to be allowed.

Yeah, that's what I'm suggesting. But I didn't realize these were used for bug fixes as well. Unfortunately, `x.y.z` doesn't appear to be allowed.
anonfunc commented 2024-08-07 20:33:14 +02:00
Owner
Copy Link

I guess he wants to say, instead of setting .1 for each rebuild, set .2 for V2, .3 for v3 and .4 for v4.
That way, the highest feature level will always be the one that gets used, no matter if it only gets available in a further rebuild.

Doing a bugfix rebuild, that in the past got the .2 would need to get .5, .6 and .7 (or .12, .13, .14)

This would still require setting all repos tho, so the benefit would be very minimal.

Unfortunately, x.y.z doesn't appear to be allowed.

Indeed, the official spec is x.y, where y is a "patch version".

> I guess he wants to say, instead of setting .1 for each rebuild, set .2 for V2, .3 for v3 and .4 for v4. > That way, the highest feature level will always be the one that gets used, no matter if it only gets available in a further rebuild. > > Doing a bugfix rebuild, that in the past got the .2 would need to get .5, .6 and .7 (or .12, .13, .14) This would still require setting all repos tho, so the benefit would be very minimal. > Unfortunately, `x.y.z` doesn't appear to be allowed. Indeed, the official spec is x.y, where y is a "patch version".
Stebalien commented 2024-08-07 20:37:31 +02:00
Copy Link

Yeah, fair enough.

Yeah, fair enough.
BS86 commented 2024-08-07 20:38:12 +02:00
Copy Link

This would still require setting all repos tho, so the benefit would be very minimal.

Yes, but it would "fix" that:

The only drawback would be that if that package is later available on v3, pacman would not automatically update to v3 until a new version is released.

> This would still require setting all repos tho, so the benefit would be very minimal. Yes, but it would "fix" that: > The only drawback would be that if that package is later available on v3, pacman would not automatically update to v3 until a new version is released.
anonfunc commented 2024-08-07 20:53:13 +02:00
Owner
Copy Link

True, but there are a lot of weird edge cases I would like to avoid.

For example, suppose the Arch version for an imaginary package is 22.6.0-1.

If I understand correctly, with this scheme we would have

Repo Version
vanilla 22.6.0-1
v2 22.6.0-1.1
v3 22.6.0-1.2
v4 22.6.0-1.3

That's all well and good. But what happens if Arch releases 22.6.0-1.1? Then we would have

Repo Version
vanilla 22.6.0-1.1
v2 22.6.0-1.4
v3 22.6.0-1.5
v4 22.6.0-1.6

The first problem would be that we would have to keep track of this mess, and the next would be that the vanilla and ALHP package rels would overlap slightly. Suppose the package fails to build with 22.6.0-1.1 (and is removed), then a user who previously had 1.1 installed would not get 1.1 from vanilla because their local version is still the same.

True, but there are a lot of weird edge cases I would like to avoid. For example, suppose the Arch version for an imaginary package is `22.6.0-1`. If I understand correctly, with this scheme we would have | Repo | Version | |---|---| | vanilla | 22.6.0-1 | | v2 | 22.6.0-1.1 | | v3 | 22.6.0-1.2 | | v4 | 22.6.0-1.3 | That's all well and good. But what happens if Arch releases `22.6.0-1.1`? Then we would have | Repo | Version | |---|---| | vanilla | 22.6.0-1.1 | | v2 | 22.6.0-1.4 | | v3 | 22.6.0-1.5 | | v4 | 22.6.0-1.6 | The first problem would be that we would have to keep track of this mess, and the next would be that the vanilla and ALHP package rels would overlap slightly. Suppose the package fails to build with `22.6.0-1.1` (and is removed), then a user who previously had 1.1 installed would not get 1.1 from vanilla because their local version is still the same.
BS86 commented 2024-08-08 12:11:46 +02:00
Copy Link

I understand that.

What about starting alhp rebuilds with .2 for V2 and for bugfix rebuilds use .12 - meaning the first digit indicates the rebuild, the second still indicates the version?
I haven't seen that arch uses .1 - do they really do that?

I understand that. What about starting alhp rebuilds with .2 for V2 and for bugfix rebuilds use .12 - meaning the first digit indicates the rebuild, the second still indicates the version? I haven't seen that arch uses .1 - do they really do that?
anonfunc commented 2024-08-08 12:40:19 +02:00
Owner
Copy Link

Arch uses it, and why shouldn't they, its a documented feature.

You would still have overlapping versions, just further down the line. I know we probably would never reach those numbers, but its still dodgy.

[Arch uses it](https://archlinux.org/packages/extra/any/distribution-gpg-keys/), and why shouldn't they, its a documented feature. You would still have overlapping versions, just further down the line. I know we probably would never reach those numbers, but its still dodgy.
tjw123hh commented 2025-05-04 04:37:34 +02:00
Copy Link

True, but there are a lot of weird edge cases I would like to avoid.

For example, suppose the Arch version for an imaginary package is 22.6.0-1.

If I understand correctly, with this scheme we would have

Repo Version
vanilla 22.6.0-1
v2 22.6.0-1.1
v3 22.6.0-1.2
v4 22.6.0-1.3

That's all well and good. But what happens if Arch releases 22.6.0-1.1? Then we would have

Repo Version
vanilla 22.6.0-1.1
v2 22.6.0-1.4
v3 22.6.0-1.5
v4 22.6.0-1.6

The first problem would be that we would have to keep track of this mess, and the next would be that the vanilla and ALHP package rels would overlap slightly. Suppose the package fails to build with 22.6.0-1.1 (and is removed), then a user who previously had 1.1 installed would not get 1.1 from vanilla because their local version is still the same.

I think some overlap between the vanilla and ALHP package pkgrels is inevitable, even without adopting a x.y versioning scheme where x reflects the upstream pkgrel and y the architecture-specific revision. Instead of trying to prevent such overlap entirely, we should address the potential issues it causes in other ways. For example, if a package like 22.6.0-1.1 fails to build and gets removed, a user who had 1.1 installed wouldn't receive the vanilla version because the version number matches. One possible solution could be to retain a vanilla copy in the ALHP repo in such cases—perhaps with a note in the PKGBUILD to clarify its purpose.

As for the point that x.y.z may not be allowed, I believe pacman does support this—vercmp, for instance, handles such versions correctly.

> True, but there are a lot of weird edge cases I would like to avoid. > > For example, suppose the Arch version for an imaginary package is `22.6.0-1`. > > If I understand correctly, with this scheme we would have > > | Repo | Version | > |---|---| > | vanilla | 22.6.0-1 | > | v2 | 22.6.0-1.1 | > | v3 | 22.6.0-1.2 | > | v4 | 22.6.0-1.3 | > > That's all well and good. But what happens if Arch releases `22.6.0-1.1`? Then we would have > > | Repo | Version | > |---|---| > | vanilla | 22.6.0-1.1 | > | v2 | 22.6.0-1.4 | > | v3 | 22.6.0-1.5 | > | v4 | 22.6.0-1.6 | > > The first problem would be that we would have to keep track of this mess, and the next would be that the vanilla and ALHP package rels would overlap slightly. Suppose the package fails to build with `22.6.0-1.1` (and is removed), then a user who previously had 1.1 installed would not get 1.1 from vanilla because their local version is still the same. I think some overlap between the vanilla and ALHP package `pkgrel`s is inevitable, even without adopting a `x.y` versioning scheme where `x` reflects the upstream `pkgrel` and `y` the architecture-specific revision. Instead of trying to prevent such overlap entirely, we should address the potential issues it causes in other ways. For example, if a package like `22.6.0-1.1` fails to build and gets removed, a user who had `1.1` installed wouldn't receive the vanilla version because the version number matches. One possible solution could be to retain a vanilla copy in the ALHP repo in such cases—perhaps with a note in the PKGBUILD to clarify its purpose. As for the point that `x.y.z` may not be allowed, I believe pacman does support this—`vercmp`, for instance, handles such versions correctly.
anonfunc commented 2025-05-04 12:12:29 +02:00
Owner
Copy Link

I think some overlap between the vanilla and ALHP package pkgrels is inevitable, even without adopting a x.y versioning scheme where x reflects the upstream pkgrel and y the architecture-specific revision. Instead of trying to prevent such overlap entirely, we should address the potential issues it causes in other ways. For example, if a package like 22.6.0-1.1 fails to build and gets removed, a user who had 1.1 installed wouldn't receive the vanilla version because the version number matches. One possible solution could be to retain a vanilla copy in the ALHP repo in such cases—perhaps with a note in the PKGBUILD to clarify its purpose.

I do not see the specific problem here though. Yes, he would not get the vanilla version until an Arch update increases the pkgrel over the old one. But that is not solved by keeping a vanilla package. In this case, ALHP would need to build a vanilla package and push it with a higher version. Not very desirable imho. If the removed package really is problematic, the user can always downgrade manually. If not, he can easily wait for the next Arch release.

As for the point that x.y.z may not be allowed, I believe pacman does support this—vercmp, for instance, handles such versions correctly.

pacman does not support x.y.z in pkgrel: https://man.archlinux.org/man/extra/alpm-docs/alpm-pkgrel.7.en

> I think some overlap between the vanilla and ALHP package `pkgrel`s is inevitable, even without adopting a `x.y` versioning scheme where `x` reflects the upstream `pkgrel` and `y` the architecture-specific revision. Instead of trying to prevent such overlap entirely, we should address the potential issues it causes in other ways. For example, if a package like `22.6.0-1.1` fails to build and gets removed, a user who had `1.1` installed wouldn't receive the vanilla version because the version number matches. One possible solution could be to retain a vanilla copy in the ALHP repo in such cases—perhaps with a note in the PKGBUILD to clarify its purpose. I do not see the specific problem here though. Yes, he would not get the vanilla version until an Arch update increases the pkgrel over the old one. But that is not solved by keeping a vanilla package. In this case, ALHP would need to build a vanilla package and push it with a higher version. Not very desirable imho. If the removed package really is problematic, the user can always downgrade manually. If not, he can easily wait for the next Arch release. > > As for the point that `x.y.z` may not be allowed, I believe pacman does support this—`vercmp`, for instance, handles such versions correctly. pacman does **not** support x.y.z in pkgrel: https://man.archlinux.org/man/extra/alpm-docs/alpm-pkgrel.7.en
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked upstream
bug
Something is not working
build-failure
package build fails
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
informational
Provides information about something
invalid
Something is wrong
invalid/corrupt package
Package needs to be rebuild
packaging issue
priority: high
High priority
question
More information is needed
support
wontfix
This won't be fixed
No Label
enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
anonfunc
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ALHP/ALHP.GO#255
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?