Request to add 32 bit support
Practicalbutterfly5 opened this issue · comments
🚀 Feature Request
Checklist
- No duplicate issues/PRs
- Are you running the latest
downgraderelease from the AUR?
Background
The current version of downgrade only looks in https://archive.archlinux.org and not https://archive.archlinux32.org, as a result, it doesn't downgrade/install packages on a 32-bit system. Using --ala-url as https://archive.archlinux32.org results in Unable to downgrade
Proposed feature
Requested to use https://archive.archlinux32.org for 32-bit systems.
Hi @Practicalbutterfly5, thanks for opening this feature request.
Before #106, we actually did offer this option where the user could specify an alternative architecture with eg. the following CLI argument: --arch i686. However, we removed this option since Arch Linux no longer (officially) supports 32-bit systems. I was also not aware of the ongoing Arch Linux 32 project before this.
In terms of diffs required, I would say it is fairly straightforward to revert (plus refine) this feature. We would have to reintroduce the --arch CLI option and fine-tune the package selection menu with the relevant architectures.
In terms of philosophy, I think it fits in with downgrade being a general purpose tool that can serve various user groups out-of-the-box. Here it is very useful that the ALA directory structures are basically the same across both projects.
@pbrisbin WDYT?
In an ideal world, IMO, --ala-url https://archive.archlinux32.org should Just Work, with no further changes to downgrade. So, I'd like to understand better why it does not and see if we could reasonably treat this as a bug-fix.
As far as I can tell, this minor change makes it all work just fine:
# Set script defaults
PACMAN="pacman"
PACMAN_CONF="/etc/pacman.conf"
-DOWNGRADE_ARCH="x86_64"
+DOWNGRADE_ARCH="$(uname -m)"
DOWNGRADE_ALA_URL="https://archive.archlinux.org"
DOWNGRADE_FROM_ALA=1
DOWNGRADE_FROM_CACHE=1If I force it to i686, this works:
# ./downgrade --ala-url https://archive.archlinux32.org --ala-only l-smash
Available packages (extra):
1) l-smash 2.9.1 1 remote
2) l-smash 2.14.5 1.0 remote
3) l-smash 2.14.5 1.1 remote
4) l-smash 2.14.5 1.3 remote
5) l-smash 2.14.5 1.4 remote
+ 6) l-smash 2.14.5 2.0 remote
select a package by number: 6
:: Retrieving packages...
l-smash-2.14.5-2.0-i686 351.4 KiB 412 KiB/s 00:01 [#####################################################################################] 100%
loading packages...
:: Import PGP key 2C146C01A952AC0F, "Erich Eckner <arch32 at eckner dot net>"? [Y/n] ^C
Interrupt signal receivedI also don't think we need any options or configuration of this. I think using uname -m will always be the correct behavior.
We only ever see x86_64 packages on archive.archlinux.org (example). Running dowgrade against that from an i686 system will (and should) find no results. On archive.archlinux32.org (example), there is more variablility (i686, i486, etc), and dowgrade will (and should) limit results to any| the actual machine's architecture. In all cases, I think this is the right behavior.
WDYT @atreyasha ?
We should probably improve the error message for the no-results case as part of this. Unable to downgrade x is pretty uninformative.
I think using
uname -mwill always be the correct behavior.
On my machine uname -m returns i686, but all my packages have pentium4 architecture. As explained here, pacman checks for flags in /proc/cpuinfo for correct architecture for machine. i686 packages fail to install on my machine, because pacman refuses to install it.
Here is my install log
[whyred@whyred ~]$ sudo downgrade nss
Available packages (core):
1) nss 3.27.2 1 remote
2) nss 3.28.1 1 remote
3) nss 3.29 1 remote
4) nss 3.29.1 1 remote
5) nss 3.29.2 1 remote
6) nss 3.29.3 1 remote
7) nss 3.29.3 2 remote
8) nss 3.30 1 remote
9) nss 3.30.1 1 remote
10) nss 3.30.2 1 remote
11) nss 3.31 1 remote
12) nss 3.31 2 remote
13) nss 3.31 3 remote
14) nss 3.32 1 remote
15) nss 3.33 1 remote
16) nss 3.33 2 remote
17) nss 3.35 1.0 remote
18) nss 3.36 1.0 remote
19) nss 3.36.1 1.0 remote
20) nss 3.37 1.0 remote
21) nss 3.37.1 1.0 remote
22) nss 3.37.3 1.0 remote
23) nss 3.38 1.0 remote
24) nss 3.38 1.1 remote
25) nss 3.39 1.0 remote
26) nss 3.39 1.1 remote
27) nss 3.39 1.4 remote
28) nss 3.39 1.5 remote
29) nss 3.40 1.0 remote
30) nss 3.40 2.0 remote
31) nss 3.40.1 1.0 remote
32) nss 3.41 1.0 remote
33) nss 3.41.1 1.0 remote
34) nss 3.42 1.0 remote
35) nss 3.42.1 1.0 remote
36) nss 3.43 1.0 remote
37) nss 3.44 1.0 remote
38) nss 3.44.1 1.0 remote
39) nss 3.45 1.0 remote
40) nss 3.45 1.1 remote
41) nss 3.46 1.0 remote
42) nss 3.46 1.1 remote
43) nss 3.46.1 1.0 remote
44) nss 3.47 1.0 remote
45) nss 3.47 2.0 remote
46) nss 3.47.1 1.0 remote
47) nss 3.47.1 4.0 remote
48) nss 3.47.1 5.0 remote
49) nss 3.48 1.0 remote
50) nss 3.49 1.0 remote
51) nss 3.49.1 1.0 remote
52) nss 3.49.1 2.0 remote
53) nss 3.49.2 1.0 remote
54) nss 3.49.2 1.1 remote
55) nss 3.49.2 1.3 remote
56) nss 3.49.2 2.0 remote
57) nss 3.49.2 3.0 remote
58) nss 3.50 1.0 remote
59) nss 3.51 1.0 remote
60) nss 3.51.1 1.0 remote
61) nss 3.52 1.0 remote
62) nss 3.52.1 2.0 remote
63) nss 3.53 1.0 remote
64) nss 3.53.1 1.0 remote
65) nss 3.54 1.0 remote
66) nss 3.55 2.0 remote
67) nss 3.56 1.0 remote
68) nss 3.57 1.0 remote
69) nss 3.58 1.0 remote
70) nss 3.58 2.0 remote
71) nss 3.59 1.0 remote
72) nss 3.60 1.0 remote
73) nss 3.60.1 1.0 remote
74) nss 3.61 1.0 remote
75) nss 3.62 1.0 remote
76) nss 3.63 1.0 remote
77) nss 3.64 1.0 remote
78) nss 3.65 1.0 remote
79) nss 3.66 1.0 remote
80) nss 3.67 1.0 remote
81) nss 3.68 1.0 remote
82) nss 3.69 1.0 remote
83) nss 3.69.1 1.0 remote
84) nss 3.70 1.0 remote
85) nss 3.71 1.0 remote
86) nss 3.72 1.0 remote
87) nss 3.72 2.0 remote
+ 88) nss 3.73 1.0 remote
select a package by number: 83
:: Retrieving packages...
nss-3.69.1-1.0-i686 1226.7 KiB 800.7 KiB/s 00:05[#########################################] 100%
loading packages...
warning: downgrading package nss (3.73-1.0 => 3.69.1-1.0)
error: failed to prepare transaction (package architecture is not valid)
:: package nss-3.69.1-1.0-i686 does not have a valid architecture
Using DOWNGRADE_ARCH="pentium4", successfully downgraded it for me. Perhaps we need an alternate way to detect package architecture.
Ah interesting!
In that case, I'd say:
: "${DOWNGRADE_ARCH:="$(uname -m)"}"That is, use uname -m unless already specified.
You can run
DOWNGRADE_ARCH=pentium4 downgrade --ala-url ...Would that work?
I defer to @atreyasha if we want to add (back) the corresponding CLI option, but this feels edge-casey enough that perhaps environment-variable-only is enough.
That is, use
uname -munless already specified.
Just found out that we can use pacman-conf Architecture to get the arch that pacman uses (which returns pentium4 on my system)
DOWNGRADE_ARCH="$(pacman-conf Architecture)"
Also we can use DOWNGRADE_ALA_URL="https://archive.archlinux32.org" if uname -m returns i686.
In an ideal world, IMO, --ala-url https://archive.archlinux32.org should Just Work, with no further changes to downgrade
True and agreed, keeps things minimal.
I defer to @atreyasha if we want to add (back) the corresponding CLI option, but this feels edge-casey enough that perhaps environment-variable-only is enough.
As much as possible, I would like to only have CLI options alter the behaviour of downgrade. IMO it just makes things simpler than having a combination of both CLI options and environment variables modifying behaviour. But based on what @Practicalbutterfly5 wrote in their last message, altering CLI options should not be necessary either.
Just found out that we can use pacman-conf Architecture to get the arch that pacman uses (which returns pentium4 on my system)
DOWNGRADE_ARCH="$(pacman-conf Architecture)"
Using pacman-conf Architecture instead of uname -m sounds like the best case scenario here since pacman-conf guarantees that it will return the same configuration values which pacman itself would use.
Also we can use DOWNGRADE_ALA_URL="https://archive.archlinux32.org" if uname -m returns i686.
Hmm, I am not so sure about this one. IMO the default DOWNGRADE_ALA_URL should stay as https://archive.archlinux.org since this is the URL officially supported by Arch Linux. Rather than adding logic to resolve this based on architecture (on our end), I think it makes more sense for the user to modify this in their own configuration file as per here.
@pbrisbin @Practicalbutterfly5 WDYT?
If you guys agree, I will start working on a PR soon.
We should probably improve the error message for the no-results case as part of this. Unable to downgrade x is pretty uninformative
Good point, will open a separate issue for this.
Agree with all points @atreyasha
I had no idea pacman-conf was a thing, and that certainly sounds great. Can we / should we use it for all of our /etc/pacman.conf-reading needs?
I agree that defaulting an alternative ALA_URL depending on ARCH is complexity that is not worthwhile. The configuration file is an excellent workaround for 32bit users, IMO.
I had no idea pacman-conf was a thing, and that certainly sounds great.
Me neither, it appears to be not very well documented; at least on the web that is.
Can we / should we use it for all of our /etc/pacman.conf-reading needs?
I think that is a good idea, so that we can use an upstream (and actively maintained) tool instead of manually grepping lines. That would make things robust to possible upstream changes as well.
Will open a separate issue for this to keep things modular.