LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Making slackpkg $ROOT aware (https://www.linuxquestions.org/questions/slackware-14/making-slackpkg-%24root-aware-4175600630/)

burdi01 02-26-2017 11:58 AM

Making slackpkg $ROOT aware
 
For the maintenance of my live CD/USB I use {install,upgrade,remove}pkg with the ROOT parameter. E.g. when SQFS is the directory I unsquashed the root filesystem in:
Code:

ROOT="$(readlink -f SQFS/squashfs-root)"  # absolute path
ROOT=$ROOT upgradepkg <package>

This requires me to manually keep track of which packages have to be upgraded. Enter slackpkg to do this for me. Alas asis slackpkg works for the current Slackware installation, not my live CD/USB one.
When looking at the /usr/sbin/slackpkg script I saw that I can override the configuration directory with a CONF parameter. In that configuration directory there is the slackpkg.conf file which sets a.o. the TEMP download and WORKDIR filelists directories. I could hardcode those directories, but using the ROOT parameter seems more appropriate:
Code:

--- slackpkg.conf.orig        2013-05-22 22:11:21.000000000 +0200
+++ slackpkg.conf        2017-02-22 17:51:51.903474693 +0100
@@ -65,10 +65,10 @@
 #SLACKKEY="Slackware Linux Project <security@slackware.com>"
 
 # Downloaded files will be in directory below:
-TEMP=/var/cache/packages
+TEMP=$ROOT/var/cache/packages
 
 # Package lists, file lists, and others will be at WORKDIR:
-WORKDIR=/var/lib/slackpkg
+WORKDIR=$ROOT/var/lib/slackpkg
 
 # Special options for wget (default is WGETFLAGS="--passive-ftp")
 WGETFLAGS="--passive-ftp"

So invoking slackpkg as e.g.:
Code:

ROOT="$(readlink -f SQFS/squashfs-root)"  # absolute path
CONF="$ROOT/etc/slackpkg"
ROOT=$ROOT CONF=$CONF slackpkg update
ROOT=$ROOT CONF=$CONF slackpkg upgrade-all

should do the trick for me.

Note that we copied the /etc/slackpkg configuration directory to /SQFS/squashfs-root/etc/slackpkg and amended the slackpkg.conf file in there. Actually we could have amended the "host" slackpkg.conf file instead (and invoke slackpkg without the CONF parameter), but separating the "host" and "live" configurations makes it possible to change other arguments (such as the slackware version and mirror) as well.

There are some minor hickups though:
-- an (empty) "live" /var/lib directory has to be created;
-- the "host" /usr/libexec/slackpkg/pkglist.awk file has to be amended:
Code:

--- pkglist.awk.orig        2011-04-05 07:54:29.000000000 +0200
+++ pkglist.awk        2017-02-25 15:07:56.475443446 +0100
@@ -3,7 +3,7 @@
                fs=FS
                FS="/" ; OFS="/"
                $0=INPUT
-                if ( $2 != "var" ) {
+                if ( $(NF-3) != "var" ) {
                        DIR=$2
                        FULLPACK=$NF
                } else {

:D

burdi01 02-27-2017 06:50 AM

Actually /usr/libexec/slackpkg/core-functions.sh as distributed already contains a lot of (and /usr/libexec/slackpkg/function.d/dialog-functions.sh one) $ROOT references: all are in the form of the (pkgtools-compatible) "$ROOT/var/log/packages" phrase.
Now have a look at the "if ( $2 != "var" )" test in the /usr/libexec/slackpkg/pkglist.awk script: only when $ROOT is empty (or non-existent) that test will succeed! With a non-empty $ROOT the test will fail and slackpkg will malfunction. Changing that test to "if ( $(NF-3) != "var" )" will make the test succeed in both cases.

By implication there are no users running slackpkg as distributed with the $ROOT argument. This means that whether or not $ROOT is added to the TEMP and WORKDIR settings in /etc/slackpkg/slackpkg.conf becomes a matter of taste. I would say it should, but otherwise an alternative slackpkg.conf (via the $CONF argument) is also a possibility.

So my requests are:
-- amend the /usr/libexec/slackpkg/pkglist.awk script -- see the diff in yesterday's posting;
-- amend the /etc/slackpkg/slackpkg.conf file -- see the diff in yesterday's posting;
-- create the $WORKDIR directory if not present -- e.g. in /usr/libexec/slackpkg/core-functions.sh system_setup():
Code:

--- core-functions.sh.orig        2015-12-16 08:01:12.000000000 +0100
+++ core-functions.sh        2017-02-27 14:07:46.470996891 +0100
@@ -57,6 +57,8 @@
 # System setup
 #
 function system_setup() {
+        # Create $WORKDIR if not present
+        mkdir -p "$WORKDIR"
 
        # Set LOCAL if mirror isn't through network
        # If mirror is through network, select the command to fetch

:D

rworkman 12-30-2017 01:14 AM

Grab the git repo here: https://git.rlworkman.net/slackpkg/

Code:

git clone git://git.rlworkman.net/slackpkg
git checkout burdi01
su -
VERSION=2.82.3_burdi01 sh slackpkg.SlackBuild

I implemented your changes in such a way that a change to slackpkg.conf is hopefully not needed - if I'm correct, simply passing ROOT= (and optionally CONF= but it might not be needed any more) will work for you.

burdi01 12-30-2017 11:12 AM

Had a look at the commits.
For as far as I am aware adding the $ROOT to the TMPDIR creation is superfluous, the "host's" /tmp should suffice. Actually my testing (see below) showed the "new" TMPDIR creation will fail if $ROOT/tmp does not exist yet.
Just curious: what is the advantage of amending mkdirs etc. all over the place over just amending two config lines?

I then cloned the git and tried to check out the burdi01 branch. I have no git experience to speak of so it took me quite some time to figure out that you forgot a "cd slackpkg" in the instructions.
Once that hurdle was taken I ran the slackbuild. Apart from the TMPDIR remark above the generated package fulfills my use case.
Regards, Dick
:D

rworkman 12-30-2017 04:08 PM

Quote:

Originally Posted by burdi01 (Post 5799701)
Had a look at the commits.
For as far as I am aware adding the $ROOT to the TMPDIR creation is superfluous, the "host's" /tmp should suffice. Actually my testing (see below) showed the "new" TMPDIR creation will fail if $ROOT/tmp does not exist yet.

Fixed (I think - please confirm) in 67bac419a3 (same burdi01 branch).

Quote:

Just curious: what is the advantage of amending mkdirs etc. all over the place over just amending two config lines?
Users are expected to read the config files, and it seems to me that having a $ROOT in there would be confusing. Users are not expected to read the slackpkg script (and support files), so hiding it away in there seems the better approach. In short, users who don't need nor care about this new functionality can remain blissfully ignorant.

Quote:

I then cloned the git and tried to check out the burdi01 branch. I have no git experience to speak of so it took me quite some time to figure out that you forgot a "cd slackpkg" in the instructions.
Once that hurdle was taken I ran the slackbuild. Apart from the TMPDIR remark above the generated package fulfills my use case.
Regards, Dick
:D
Good deal - thanks for testing.

Of course, I can't promise that this will be accepted, but once you tell me it works for you, I'll do another prerelease to get some wider testing.

Didier Spaier 12-30-2017 05:31 PM

Robby , while you are at it, two small suggestions:
  1. Be a little more lenient with mirrors' URL syntax: instead of have slackpkg --update fail for a missing trailing solidus in the URL, remove the solidus if it exists then add it.
  2. Warn the user who chose a version or architecture not matching that of the target system. We have seen too many people sorry after having picked a wrong mirror. Not sure how to check the version, though.
I don't use slackpkg any more, but still...


Greetings,

burdi01 12-31-2017 06:49 AM

Quote:

Fixed (I think - please confirm) in 67bac419a3 (same burdi01 branch).
Confirmed.

I now have tested ok my use case: slackpkg update, install, reinstall, upgrade-all and remove.

Kind regards,
Dick :D

rworkman 01-03-2018 01:02 AM

https://slackpkg.org/beta/slackpkg-2...arch-1_rlw.txz

rworkman 01-03-2018 01:07 AM

Quote:

Originally Posted by Didier Spaier (Post 5799799)
Robby , while you are at it, two small suggestions:
  1. Be a little more lenient with mirrors' URL syntax: instead of have slackpkg --update fail for a missing trailing solidus in the URL, remove the solidus if it exists then add it.

  1. Well, that's not necessarily a terrible idea; I'll have to dig around in there a bit more and try to find where that happens. I see some instances where it's clear that's what's happening, but it didn't jump out at me where exactly to fix it.

    Quote:

  2. Warn the user who chose a version or architecture not matching that of the target system. We have seen too many people sorry after having picked a wrong mirror. Not sure how to check the version, though.
I don't know of a good way to do this without tripping over people intentionally going from -stable to -current.

I guess some sort of warning that e.g. "14.2" != "current" which requires confirmation would be fine, but it would only need to happen the first time. That's low on my priority list, but I won't necessarily reject it (or the first one) if someone else wants to implement it.

Didier Spaier 01-06-2018 04:11 PM

2 Attachment(s)
Hello,

Quote:

Originally Posted by rworkman (Post 5800910)
I guess some sort of warning that e.g. "14.2" != "current" which requires confirmation would be fine, but it would only need to happen the first time. That's low on my priority list, but I won't necessarily reject it (or the first one) if someone else wants to implement it.

The attached patches are against slackpkg-2.82.2-noarch-1.

rworkman 01-06-2018 04:26 PM

Quote:

Originally Posted by Didier Spaier (Post 5803048)
Hello,

The attached patches are against slackpkg-2.82.2-noarch-1.

Very nice - thanks :-)

What do you mean by this?
Code:

+      # Are cdrom and local really relevant?

Didier Spaier 01-06-2018 04:34 PM

I mean: isn't the scheme file:// good enough for all local files?

On the other hand maybe I am missing other schemes for unofficial remote mirrors like on a samba share, whatever.

Darth Vader 01-06-2018 04:40 PM

You guys can do something about the offering to update LILO? Read: removing it or transforming it in whatever plugin?

Was demonstrated in the past that it can be nonfunctional and prone to create confusion.

And anyway there are many other ways than LILO to boot Slackware, i.e. elilo, grub, syslinux, etc...

PS. I never used (and I never will do) that slackpkg then does not affect me personally, if someone think that I will have some personal profit. :p

rworkman 01-06-2018 05:23 PM

I use local:// since a long time ago here (nfs-mounted trees), so I'm reluctant to change anything in that regard :-)

Re the patches, they are pushed to a "didier" branch as follows:
Code:

commit 000fcef0ed53495119526d6fcf4b588749e849b6 (HEAD -> didier, origin/didier)
Author: Didier Spaier <didier [at] slintDoTfr>
Date:  Sat Jan 6 17:19:27 2018 -0600

    files/slackpkg: SOURCE handling - land softer if no trailing /

commit 72444c0a9dfd678242409ca40862379226e45a85
Author: Didier Spaier <didier [at ] slintDoTfr>
Date:  Sat Jan 6 17:15:01 2018 -0600

    core-functions.sh: Warn (first time) if -current mirror is selected
   
    Require confirmation the first time a -current mirror is selected.

I'll do some local tests to make sure neither of us stuffed anything up (I had to apply them manually because the patches got munged somehow, maybe by the forum, or maybe due to space/tab issues). Assuming local tests are passed, I'll spin up a new beta5 with these patches and try to wrap things up.

rworkman 01-06-2018 05:26 PM

Quote:

Originally Posted by Darth Vader (Post 5803061)
You guys can do something about the offering to update LILO? Read: removing it or transforming it in whatever plugin?

Was demonstrated in the past that it can be nonfunctional and prone to create confusion.

And anyway there are many other ways than LILO to boot Slackware, i.e. elilo, grub, syslinux, etc...

PS. I never used (and I never will do) that slackpkg then does not affect me personally, if someone think that I will have some personal profit. :p

I'm not sure what the best approach to this is, really.

I'm inclined to say that slackpkg shouldn't offer to do anything - just tell the user that the kernel image changed and to make sure that some appropriate action is taken. However, I suspect that will break somebody's work flow somewhere, and that somebody will be even angrier (and for better reason) than all of the folks angry that slackpkg is offering to do something useless. After all, if we have to choose between "useless" and "harmful," it seems that useless is the better choice.

I have an idea for how to make both groups happy, so I'll see about implementing that...


All times are GMT -5. The time now is 12:37 PM.