SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Have you looked at what /sbin/upgradepkg actually does?
The only think i looked is when install/upgrade ca-certificates out of default / i need make a manual intervention.
ROOT=$MYDIR upgradepkg ca-certificates , does the upgrade but ...........
Code:
# We don't want to run this from the installer because we've got a script
# that runs it after all the packages are installed. But if we do run it,
# we should chroot into the target partition to make sure the updates are
# done in the correct location (and not on the calling partition):
if [ ! -r /usr/lib/setup/setup ]; then
chroot . /usr/sbin/update-ca-certificates --fresh 1> /dev/null 2> /dev/null
fi
The afterinstall tasks never work ... no see $ROOT
I think all packages with doinst files, fails when --root or ROOT= are used as argument.
I think the correct are
Quote:
if [ ! -r $ROOT/usr/lib/setup/setup ]; then
chroot . $ROOT/usr/sbin/update-ca-certificates --fresh 1> /dev/null 2> /dev/null
fi
I need every update manually execute
update-ca-certificates
when i installed out of default /
ssl certificates under /etc/ssl/certs never upgraded if no manual intervention.
Sorry for my very bad english , hope i exposed correctly the --root ROOT usage problem when "after install/upgrade" tasks need to execute with a doinst file.
A good exmaple is when you have a live system and need to mantain , need a real system installed to make this type of after install tasks , to get the files and package in the live system.
The doinst problem when use an extra argumento "root=" ,is nothing new , its a very old problem.
Last edited by USUARIONUEVO; 01-10-2023 at 06:33 PM.
The only think i looked is when install/upgrade ca-certificates out of default / i need make a manual intervention.
ROOT=$MYDIR upgradepkg ca-certificates , does the upgrade but ...........
Code:
# We don't want to run this from the installer because we've got a script
# that runs it after all the packages are installed. But if we do run it,
# we should chroot into the target partition to make sure the updates are
# done in the correct location (and not on the calling partition):
if [ ! -r /usr/lib/setup/setup ]; then
chroot . /usr/sbin/update-ca-certificates --fresh 1> /dev/null 2> /dev/null
fi
The afterinstall tasks never work ... no see $ROOT
I think all packages with doinst files, fails when --root or ROOT= are used as argument.
...
I need every update manually execute
Well, the file /usr/lib/setup/setup exists only in the installer's initrd and it's the installer script.
So, the chrooting is executed only when the package installation is not made from installer, where's another way to update the ca-certificates, at final. And the chroot command it's correct, because it's executed AFTER chrooting.
Now, it's debatable if there is a real use case when the user should use the installer's initrd as rescue system and to install/upgrade fully the ca-certificates in a target system. IF yes, then probably Slackware should ship a real alternate "rescue" initrd with no installer included. After all, those initrds are quite small in the economy of the installation media.
HOWEVER, I believe that what Master Fulalas wants is impossibile with the current design of the Slackware PKGTOOLS. Because those tools are designed to work over a fully installed system in the target and he wants to get a nice tree, with all package files prepared in the /tmp/module-ca-certificates when he executes as example:
WHY? Because this /usr/sbin/update-ca-certificates is a script, supposed to be executed by Bash, and there on /tmp/module-ca-certificates is no Bash installed.
True, there are solutions, BUT I believe that those solutions should be made by the developers of the Slackware derived distributions.
For example, to generate those stand-alone trees of installed packages, the Porteus may use a modified installpkg which do chroot in the target system before executing the install/doinst.sh script and to make a Porteus modules generator which binds the / (system root) to the target directory under an UNIONFS, so the installation of package would be exactly like in the real system, BUT they can grab the files of that particular XZM module only. However, this is not our business, but theirs.
BUT, I for one, I do NOT think that Slackware itself should (or it should be modified to) support the Porteus quirks, for example.
Of course, I do not exclude the case when they donate an indecent amount of moneys to our BDFL, big enough to make him to reserve a week or two for writing a custom tailored PKGTOOLS and makemod for them.
Last edited by LuckyCyborg; 01-11-2023 at 01:08 AM.
* Fix the evaluation of the autoconnect retries.
* nm-cloud-setup now preserves addresses added externally.
* Ensure that dnsmasq is stopped after changing the dns backend and
restarting the service.
* Fix honoring an explicit DHCPv6 DUID with dhclient.
* Other various fixes.
Rust 1.66.1 fixes Cargo not verifying SSH host keys when cloning dependencies or registry indexes with SSH.
This security vulnerability is tracked as CVE-2022-46176, and you can find more details in the advisory.
I only write cause changelog say "patched" ,but i think not true.
Make a folder , and send ca-certificates to install on this folder, you see how de certificates are not generated under FOLDER/etc/ssl/certs , package installs IN YOUR folder , but no afterinstall tasks works., but doinst not work when use --root or ROOT=MYFOLDER , thats all.
I understand perfectly if some tool are not present on DESTDIR folder , some things cant work , but why ? if the tools required to the actions are under / as you say example bash ... i have /bin/bash , action are posible, but the afterinstall tasks no respect like DESTDIR ..
Repair or not , i know the limitations since years , and i can live with this ... in my case on a installed system or live system , execute de doinst tasks and get the generated files to put inside my custom folder.
And as a final question , why exists the parameter --root or ROOT= if not 100x100 viable ? other way is put a variable ROOT on the update-ca-certificates script to generate the ssl certs under MYFOLDER/etc/ssl/certs when use --root parameter.
In all cases i think the root parameter is not 100% working.
Can write what you want ...
installpkg or upgradepkg --root YOURFOLDER ca-certicates NEVER do the ssl certs , you can test easily , no write more arround this i konow the problems and i know how to solve , but "patch" are not true from the changelog , cause not 100% --root parameter work.
Last edited by USUARIONUEVO; 01-11-2023 at 04:43 PM.
In all cases i think the root parameter is not 100% working.
That's not true
update-ca-certificates is 0% working with the --root parameter
EDIT:
ok I get it
It doesn't make sense to install ssl certs in your home folder
the doinst.sh for update-ca-certificates contains "chroot .", it means that "." became your root partition, and assumes that you have a full system installed in it
You can't chroot into your home $FOLDER directory unless you have a system tree in that directory
I only write cause changelog say "patched" ,but i think not true.
Make a folder , and send ca-certificates to install on this folder, you see how de certificates are not generated under FOLDER/etc/ssl/certs , package installs IN YOUR folder , but no afterinstall tasks works., but doinst not work when use --root or ROOT=MYFOLDER , thats all.
I understand perfectly if some tool are not present on DESTDIR folder , some things cant work , but why ? if the tools required to the actions are under / as you say example bash ... i have /bin/bash , action are posible, but the afterinstall tasks no respect like DESTDIR ..
Repair or not , i know the limitations since years , and i can live with this ... in my case on a installed system or live system , execute de doinst tasks and get the generated files to put inside my custom folder.
And as a final question , why exists the parameter --root or ROOT= if not 100x100 viable ? other way is put a variable ROOT on the update-ca-certificates script to generate the ssl certs under MYFOLDER/etc/ssl/certs when use --root parameter.
In all cases i think the root parameter is not 100% working.
Can write what you want ...
installpkg or upgradepkg --root YOURFOLDER ca-certicates NEVER do the ssl certs , you can test easily , no write more arround this i konow the problems and i know how to solve , but "patch" are not true from the changelog , cause not 100% --root parameter work.
I think the command you are looking for is
Code:
explodepkg
The point of installpkg is to install a package onto your system. Not extract the contents into a random directory.
Code:
$ man installpkg
INSTALLPKG(8) System Manager's Manual INSTALLPKG(8)
NAME
installpkg - install Slackware packages.
SYNOPSIS
installpkg [ --warn ] [ --md5sum ] [ --root /otherroot ] [ --infobox ] [ --menu
] [ --terse ] [ --terselength <length> ] [ --ask ] [ --priority ADD|REC|OPT|SKP
] [ --tagfile /somedir/tagfile ] [ --threads <number> ] [ --no-overwrite ] pack‐
agename [ packagename2 ... ]
DESCRIPTION
installpkg installs single or multiple *.txz (or .tbz, .tgz, .tlz) binary pack‐
ages designed for use with the Slackware Linux distribution onto your system.
I'm not sure if it was requested before, but if Vim could be built with 'with-x' option, that could really come in handy. Unless there is a reason this option is left out I'm not aware of.
I'm not sure if it was requested before, but if Vim could be built with 'with-x' option, that could really come in handy. Unless there is a reason this option is left out I'm not aware of.
I need Vim built with +clipboard, and without that I cannot copy to or (more importantly) from Vim to system clipboard. I feel it's not that unique use case unless I'm missing something here.
Gvim is GUI for Vim, it doesn't change the fact that it hasn't the mentioned build option.
I need Vim built with +clipboard, and without that I cannot copy to or (more importantly) from Vim to system clipboard. I feel it's not that unique use case unless I'm missing something here.
Gvim is GUI for Vim, it doesn't change the fact that it hasn't the mentioned build option.
So, you want Slackware to make Vim dependent on X11?
This will mean also that Vim will not work anymore in a Linux (or remote) console, right? What could go wrong with this?
Last edited by LuckyCyborg; 01-13-2023 at 03:19 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.