LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 08-30-2013, 04:13 AM   #1
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,646

Rep: Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231
[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>

Last edited by Didier Spaier; 08-30-2013 at 02:51 PM. Reason: s/in one uncomment/if one uncomment/
 
Old 08-30-2013, 04:22 AM   #2
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
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 ....
 
Old 08-30-2013, 04:35 AM   #3
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,646

Original Poster
Rep: Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231
Quote:
Originally Posted by wildwizard View Post
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?
 
Old 08-30-2013, 02:31 PM   #4
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 494

Rep: Reputation: 131Reputation: 131
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
 
Old 08-30-2013, 03:12 PM   #5
TommyC7
Member
 
Registered: Mar 2012
Distribution: Slackware, CentOS, OpenBSD, FreeBSD
Posts: 438

Rep: Reputation: Disabled
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.
 
2 members found this post helpful.
Old 08-30-2013, 03:35 PM   #6
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,646

Original Poster
Rep: Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231
Quote:
Originally Posted by TommyC7 View Post
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.
 
1 members found this post helpful.
Old 08-30-2013, 03:44 PM   #7
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,379

Rep: Reputation: Disabled
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
 
7 members found this post helpful.
Old 08-30-2013, 07:00 PM   #8
chemfire
Member
 
Registered: Sep 2012
Posts: 81

Rep: Reputation: Disabled
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Bash: Checking for lower case and upper case letters in a string fatalerror0x00 Programming 1 12-09-2012 03:17 AM
Help with sed and awk to change L-case letters to U-case for specific lines in a file rootaccess Linux - General 12 05-21-2012 03:50 PM
mkisofs -iso-level 1 converts to lower case instead of upper case. stf92 Slackware 3 10-29-2010 01:32 AM
Copying files from case-sensitive Linux to case-insensitive Windows via CIFS? SlowCoder Linux - General 4 05-07-2008 08:03 PM
Why are all my upper case files being shown as lower case?? [Kernel 2.6.9-1.667 FC3] t3gah Fedora 4 03-11-2005 05:09 PM


All times are GMT -5. The time now is 07:06 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration