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 ...........


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

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.

3 members found this post helpful.

Thanks for the head's up... I did not even know about this option
nor that it did not work "as advertised".

--- clipped from 'man upgradepkg' ---

To upgrade in a directory other than / (such as /mnt):

ROOT=/mnt upgradepkg package.txz (or .tbz, .tgz, .tlz)
___________________________________________________________________

We need a good GUI password manager for KDE/QT users, volkerdi please add this

KeepassXC : https://github.com/keepassxreboot/keepassxc

1 members found this post helpful.

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.

NetworkManager 1.40.10
https://gitlab.freedesktop.org/Netwo...-/tags/1.40.10

Rust 1.66.1

https://blog.rust-lang.org/2023/01/10/Rust-1.66.1.html

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.

1 members found this post helpful.

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 think the command you are looking for is

The point of installpkg is to install a package onto your system. Not extract the contents into a random directory.

Alien Bob's already got a package and a slackbuild for it.

2 members found this post helpful.

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.

1 members found this post helpful.

There's "vim-gvim" package in XAP for that.

1 members found this post helpful.

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.

1 members found this post helpful.

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?

Try pressing SHIFT simultaneously.