LinuxQuestions.org - [REQUEST] in installpkg, warn in case of ARCH mismatch

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - [REQUEST] in installpkg, warn in case of ARCH mismatch (https://www.linuxquestions.org/questions/slackware-14/%5Brequest%5D-in-installpkg-warn-in-case-of-arch-mismatch-4175475284/)

[REQUEST] in installpkg, warn in case of ARCH mismatch

I just installed a 64bit package in my 32bit Slackware (missing morning coffee). No big deal for one package, but very annoying e.g. if one uncomment a bad mirror in /etc/slackpkg.conf...

So, would it be possible to compare output of "uname -m" with the $ARCH part of the package name and warn the user if they don't fit?

I understand that not all packages names are built with the same template, so finding the ARCH in it (that in addition can be missing) could be tricky if we want to generalize, but at least that could work for recent Slackware packages whose name's template is ${PKG}-${VERSION}-${ARCH}-${BUILD}.t?z, leaving the check alone if a plausible ARCH can't be found in package's name.

PS Maybe our BDFL had already this in mind writing that in installpkg:

Code:

<snip>

    else # we have four or more segments, so we'll consider this a new-style name:

      NAME=$(expr $INDEX - 3)

      NAME="$(echo $STRING | cut -f 1-$NAME -d -)"

      echo $NAME

      # cruft for later ;)

      #VER=$(expr $INDEX - 2)

      #VER="$(echo $STRING | cut -f $VER -d -)"

      #ARCH=$(expr $INDEX - 1)

      #ARCH="$(echo $STRING | cut -f $ARCH -d -)"

      #BUILD="$(echo $STRING | cut -f $INDEX -d -)"

    fi

<snip>

You might get more warnings than you might expect.

Google Earth is i486
Adobe Flash is i386
Steam is i386

And every other package on my system is x86_64 ....

Quote:

Originally Posted by wildwizard (Post 5018756)

You might get more warnings than you might expect.

Google Earth is i486
Adobe Flash is i386
Steam is i386

And every other package on my system is x86_64 ....

Assuming that on your system "uname -m" returns x86_64, you would get a warning for those three. Is that wrong?

Quote:

I just installed a 64bit package in my 32bit Slackware (missing morning coffee). No big deal for one package, but very annoying e.g. in one uncomment a bad mirror in /etc/slackpkg.conf...

i once did a big system update using a mirror of the wrong architecture... it didn't end nice :)

There are a lot of other bugs in pkgtools that could use some work (e.g. installpkg with --root and --warn doesn't work, a proper doinst.sh script for weird filenames like '->', symlinks with spaces in their name, symlinks with weird names like '(dev).py', etc.). These are all very rare examples that most people probably won't run into so there's very little incentive to fix them.

Even if there is a fix for it, we have to make sure it doesn't break anything else (ANYTHING else, functionality of the pkgtools scripts, a package, etc.).

With that said, using installpkg on the wrong architecture is more of a PEBCAK sort-of thing if you ask me. Suppose you have a 64-bit system and you wish to create a 32-bit chroot in it. If you use installpkg with --root=/path/to/chroot it would have to account for the fact that the package being installed is actually a 32-bit package even though installpkg was called from a 64-bit machine.

Quote:

Originally Posted by TommyC7 (Post 5019031)

With that said, using installpkg on the wrong architecture is more of a PEBCAK sort-of thing if you ask me. Suppose you have a 64-bit system and you wish to create a 32-bit chroot in it. If you use installpkg with --root=/path/to/chroot it would have to account for the fact that the package being installed is actually a 32-bit package even though installpkg was called from a 64-bit machine.

Sure, there are cases where mixing architectures of installing/installed systems is normal. But then, a simple warning won't prevent the user to proceed.

Come on, this is Slackware. The installpkg tool will do _exactly_ what you want it to do and does not try to be your nanny.

Eric

I think the other issue here is that while ${PKG}-${VERSION}-${ARCH}-${BUILD}.t?z is the modern canonical way to name packages there currently is no hard and fast rule that says its gota be that way. ${PKG} will still install and remove just fine, ${PKG}-${VERSION} is usually enough for upgrade to work appropriately.

Now I can't think of many good reasons to name packages differently other than to add something like -sbo or -${my_initials} to the end to make it clear they are not stock packages; shifting something to a hard requirement that has only been a convention before is probably a bug.

That said the original idea of printing some kinda warning is one I'd support in general. Seems low risk in terms of breaking pkgtool and the installer.