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.
This weekend I read the topic without without a pc (with smartphone) and I was unable to read all well.
Also in the weekend I had the opportunity to consider sometime.
The 'impulsive' thoughts was past.
However:
1) never I thoughts that slackpkg+ is full mine. Who think that are very wronging. Mine is the starting idea and few other. Most of code is a your creation. And I see from the code-style that you are a good developer. I have always defined myself a 'draft-code' writer. So the of bugs is related on my part of code. But in effect the rc versions was to test it!
2) never I thoughts to really reject the 'notify' function (that I like) but only ritard the inserting. The consideration (on "it broke the slackware phylosophy?") came from the my attemping to add a feature, failed becouse it may broke the slackware phylosophy. So I was led to make considerations before insert other code.
3) yes, the typos you have reported has not been corrected from the git-version of slackpkg+, that corrects the documentation only.
4) yes, slackpkg+ is not libreoffice , so I may postpone the release of a few hours and insert the new code.
For multilib there is some considerations to do (premise that I do not use it but a my custom method that is offtopic here).
- Regardless the message "When you see NEW packages with 'slackpkg install-new' command, ...", in setupmultilib.sh, I limited it for the '-current' tree only becouse in a -stable tree the command 'install-new' always give a null output, so I think (tell me If is wrong) that also in multilib-stable tree there are not new packages, so slackpkg upgrade-all is sufficient.
- In a non-full installation of slackware, slackpkg install multilib propose to install all multilib packages, even if the related 64bit-package is not installed.
So an idea may be
1) the setupmultilib.sh in line 77
slackpkg install multilib
may be replaced by
slackpkg install `all multilib packages related to the current /var/log/packages/*`
2) the function 'slackpkg install-new' for multilib removed at post #126 may be reinserted or substituted from the last your idea:
Code:
NOTIFYMSG[on_upgrade@.*-compat32$]="The 32-bit compatibility layer has been updated.\n\
\n\
Keep in mind that, for better 32-bit support, packages will be added to this layer as\
needed. To track down those changes, and so keep your multilib up to date, you should\
run the commands below on a regular basis :\n\
$ slackpkg update && slackpkg install multilib"
but suggesting not 'install multilib' but 'install <new-installed-packages>-compat32' with 'on_install' instead 'on_upgrade', and only related to the official slackware packages.
Version 1.0 - 11/Nov/2013
- slackpkg+ 1.0 stable finally relased
- All repositories aligned to newest slackware version
- Documentation reformatting and some typo fix (thanx to idlemoor)
- Added function 'notification on event' that allow to insert reminders
when you install/ugrade/remove some packages. See slackpkgplus.conf samples.
(thanks to phenixia2003)
This weekend I read the topic without without a pc (with smartphone) and I was unable to read all well.
Also in the weekend I had the opportunity to consider sometime.
The 'impulsive' thoughts was past.
However:
1) never I thoughts that slackpkg+ is full mine. Who think that are very wronging. Mine is the starting idea and few other. Most of code is a your creation. And I see from the code-style that you are a good developer. I have always defined myself a 'draft-code' writer. So the of bugs is related on my part of code. But in effect the rc versions was to test it!
2) never I thoughts to really reject the 'notify' function (that I like) but only ritard the inserting. The consideration (on "it broke the slackware phylosophy?") came from the my attemping to add a feature, failed becouse it may broke the slackware phylosophy. So I was led to make considerations before insert other code.
3) yes, the typos you have reported has not been corrected from the git-version of slackpkg+, that corrects the documentation only.
4) yes, slackpkg+ is not libreoffice , so I may postpone the release of a few hours and insert the new code.
I'm sorry too. My words was inappropriate.
Quote:
Originally Posted by zerouno
For multilib there is some considerations to do (premise that I do not use it but a my custom method that is offtopic here).
- Regardless the message "When you see NEW packages with 'slackpkg install-new' command, ...", in setupmultilib.sh, I limited it for the '-current' tree only becouse in a -stable tree the command 'install-new' always give a null output, so I think (tell me If is wrong) that also in multilib-stable tree there are not new packages, so slackpkg upgrade-all is sufficient.
New packages can be included even in multilib-stable. For instance, Eric recently added the packages 'a/attr' and 'l/giflib' in multilib-current, multilib-14.0 and multilib-13.37. Here is a snippet from mutlilib's changelog :
Code:
+--------------------------+
Sun Oct 20 14:09:19 UTC 2013
13.37/compat32-tools-3.1-noarch-2alien.tgz: See below.
14.0/compat32-tools-3.1-noarch-2alien.tgz: See below.
current/compat32-tools-3.1-noarch-2alien.tgz: In massconvert32.sh, added
'a/attr' and 'l/giflib' for better Wine/pipelight support .
13.37/slackware64-compat32: Refreshed the *compat32 packages.
14.0/slackware64-compat32: Refreshed the *compat32 packages.
current/slackware64-compat32: Refreshed the *compat32 packages.
Therefore, 'slackpkg upgrade-all' (nor slackpkg upgrade multilib') is not sufficient to keep the multilib up to date. At a certain point, and more precisely right after 'slackpkg update', users should run 'slackpkg install multilib' to grab the newly added packages to the multilib, if any.
Quote:
Originally Posted by zerouno
- In a non-full installation of slackware, slackpkg install multilib propose to install all multilib packages, even if the related 64bit-package is not installed.
So an idea may be
1) the setupmultilib.sh in line 77
slackpkg install multilib
may be replaced by
slackpkg install `all multilib packages related to the current /var/log/packages/*`
Yes this could be done. But, I think that implies extra work that could be counterproductive: There could be a 32-bit software that requires one of the compat32 package which has not be installed because its 64-bit counterpart is not installed.
Quote:
Originally Posted by zerouno
2) the function 'slackpkg install-new' for multilib removed at post #126 may be reinserted or substituted from the last your idea:
Code:
NOTIFYMSG[on_upgrade@.*-compat32$]="The 32-bit compatibility layer has been updated.\n\
\n\
Keep in mind that, for better 32-bit support, packages will be added to this layer as\
needed. To track down those changes, and so keep your multilib up to date, you should\
run the commands below on a regular basis :\n\
$ slackpkg update && slackpkg install multilib"
but suggesting not 'install multilib' but 'install <new-installed-packages>-compat32' with 'on_install' instead 'on_upgrade', and only related to the official slackware packages.
The 'slackpkg install-new' that was removed at post #126 could be re-integrated. You're right this would be better than relying on "slackpkg install multilib" to install newly added packages to the multilib. It needs to be rewritten to select the new packages only. I have some ideas to check before going further.
New packages can be included even in multilib-stable.
Ok, I did not know that.
Quote:
Therefore, 'slackpkg upgrade-all' (nor slackpkg upgrade multilib') is not sufficient to keep the multilib up to date.
but is sufficient to keep update the already installed compat32 packages.
Quote:
At a certain point, and more precisely right after 'slackpkg update', users should run 'slackpkg install multilib' to grab the newly added packages to the multilib, if any.
unless slackpkg install-new manage it (I have not yet had the opportunity to review the past code removed)
Quote:
Quote:
So an idea may be
1) the setupmultilib.sh in line 77
slackpkg install multilib
may be replaced by
slackpkg install `all multilib packages related to the current /var/log/packages/*`
Yes this could be done. But, I think that implies extra work that could be counterproductive: There could be a 32-bit software that requires one of the compat32 package which has not be installed because its 64-bit counterpart is not installed.
but is sufficient to keep update the already installed compat32 packages.
Yes.
Quote:
Originally Posted by zerouno
unless slackpkg install-new manage it (I have not yet had the opportunity to review the past code removed)
I removed the old code because it installs all the uninstalled compat32 packages, and not only the new packages. This is not consistent with slackpkg's man page :
Quote:
install-new
This action installs any new packages that are added to [...] If you want to install all uninstalled [...] packages onto your system, use the following command
instead of the install-new action:
Correct me if I'm wrong, but I guess that you want to install only the compat32 packages for which a 64-bit version is installed. For instance, if the 64-bit package "qt" is not installed, you do not install the package "qt-compat32". You can do that, but it will be better to let the user choose if he wants a full-multilib or a customized (or a shrinked to system) multilib.
Keep in mind that you have no guarantee that all the 32-bit softwares that user could install will not require one of the compat32 packages which have not be installed because its 64-bit counterpart is not installed.
Here is an example (a bit dumb): Imagine a user who has not installed "kde" nor the package "l/qt". He installs the multilib, but, given the package "qt" is not installed, the qt-compat32 will not be installed. After that, he installs the 32-bit google-earth, but this software requires the 32-bit qt, which is not installed because the 64-bit version is not installed ...
I removed the old code because it installs all the uninstalled compat32 packages, and not only the new packages. This is not consistent with slackpkg's man page
this is true. It's also true that run 'slackpkg install multilib' then search manually for new packages and deselect all unwanted 32bit libraries AND all 32bit packages not installed becouse isn't installed the relative 64bit package EACH time isn't really practice. The new 'slackpkg install-new' should install only the 32bit libraries related to the installed 64bit installed packages so I only need to deselect unwanted 32bit libraries.
A feature that I want to add from a lot of time ago was the ability to construct a custom changelog for thirdy party repository as follow:
on every slackpkg update, for each repository:
- the downloaded CHECKSUMS.md5 is not removed but stored in /var/lib/slackpkg
- the new CHECKSUMS.md5 is comparated with the old
- the diff is stored in the changelog reformatted with Added,Upgraded,Rebuilt,Removed tags
- the downloaded CHECKSUMS.md5 override the older.
so the user will have a changelog for all repositories.
That changelog may be used from install-new for the multilib repository.
Quote:
Correct me if I'm wrong, but I guess that you want to install only the compat32 packages for which a 64-bit version is installed.
Yes. At least as starting installation.
Then if a user want to add/remove other 32bit library can add/remote it with slackpkg install/remove package-compat32.
A slackpkg install multilib need that the user search manually all not needed 32bit packages unwanted.
This is better than use slackpkg install multilib and deselect all unwanted 32bit packages.
Quote:
Keep in mind that you have no guarantee that all the 32-bit softwares that user could install will not require one of the compat32 packages which have not be installed because its 64-bit counterpart is not installed.
Tipically a compat32 library NEED the 64bit conterpart becouse the compat32 packages install only the usr/lib/ files and few other.
the qt original package contains many file in /usr/share and /etc not presents in qt-compat32.
I dont tried, but I doubt that the qt-compat32 work fine without that files.
Who really want to use 32bit qt without 64bit qt simply run slackpkg install qt-compat32 manually.
Despite the error message, downloading and installing packages using slackpkg works fine.
Another thing: zerouno, I'm currently reorganizing all my software repositories. I prefer doing this now, and then keep them that way for the coming years. The structure wasn't very flexible.
this is true. It's also true that run 'slackpkg install multilib' then search manually for new packages and deselect all unwanted 32bit libraries AND all 32bit packages not installed becouse isn't installed the relative 64bit package EACH time isn't really practice.
The new 'slackpkg install-new' should install only the 32bit libraries related to the installed 64bit installed packages so I only need to deselect unwanted 32bit libraries.
If you want only the 32-bit packages related to the installed 64-bit packages, you can simply blacklist all the 32-bit packages you don't want, and this can be automated at runtime with the "internal blacklist". sample code (not fully tested) :
if $ADAPTATIVE_MULTILIB ; then
grep "^SLACKPKGPLUS_multilib .*-compat32[ ]" ${WORKDIR}/pkglist | cut -f2 -d" " | sort > ${TMPDIR}/packages.32bit
ls -1 /var/log/packages | rev | cut -f4- -d- | rev | grep -v "[-]compat32$" | sort > ${TMPDIR}/packages.64bit
cat ${TMPDIR}/packages.32bit | rev | cut -f2- -d- | rev | sort > ${TMPDIR}/packages.64bit.filter
comm -1 -2 ${TMPDIR}/packages.64bit ${TMPDIR}/packages.64bit.filter | sed "s/.*/&-compat32/g" | sort > ${TMPDIR}/packages.32bit.filter
comm -3 ${TMPDIR}/packages.32bit ${TMPDIR}/packages.32bit.filter > ${TMPDIR}/blacklist.slackpkgplus
fi
Quote:
Originally Posted by zerouno
A feature that I want to add from a lot of time ago was the ability to construct a custom changelog for thirdy party repository as follow:
on every slackpkg update, for each repository:
- the downloaded CHECKSUMS.md5 is not removed but stored in /var/lib/slackpkg
- the new CHECKSUMS.md5 is comparated with the old
- the diff is stored in the changelog reformatted with Added,Upgraded,Rebuilt,Removed tags
- the downloaded CHECKSUMS.md5 override the older.
so the user will have a changelog for all repositories.
That changelog may be used from install-new for the multilib repository.
This would be useful.
I wrote this to ensure slackpkg install-new to only install the new packages. That seems to work, but this really needs to be tested, and surely to be reviewed.
Code:
echo "${PKGS_PRIORITY}" | grep -q "multilib:[.][*]" && MULTILIB_ENABLED=true || MULTILIB_ENABLED=false
if [ "$CMD" == "update" ] ; then
if $MULTILIB_ENABLED ; then
if [ ! -e ${WORKDIR}/compat32-list.previous ] && [ -e ${WORKDIR}/pkglist ] ; then
grep "^SLACKPKGPLUS_multilib .*-compat32[ ]" ${WORKDIR}/pkglist | cut -f2 -d" " | sort > ${WORKDIR}/compat32-list.previous
fi
else
rm -f ${WORKDIR}/compat32-list.*
fi
fi
if [ "$CMD" == "install-new" ] && $MULTILIB_ENABLED ; then
if [ -e ${WORKDIR}/compat32-list.previous ] ; then
grep "^SLACKPKGPLUS_multilib .*-compat32[ ]" ${WORKDIR}/pkglist | cut -f2 -d" " | sort > ${WORKDIR}/compat32-list.latest
ls -1 /var/log/packages/*compat32 | rev | cut -f1 -d/ | cut -f4- -d- | rev | sort > ${WORKDIR}/compat32-list.installed
comm -1 -3 ${WORKDIR}/compat32-list.previous ${WORKDIR}/compat32-list.latest | sort > ${WORKDIR}/compat32-list.new
comm -1 -3 ${WORKDIR}/compat32-list.installed ${WORKDIR}/compat32-list.new |sort > ${WORKDIR}/compat32-list.new.2
mv ${WORKDIR}/compat32-list.new.2 ${WORKDIR}/compat32-list.new
rm ${WORKDIR}/compat32-list.previous ${WORKDIR}/compat32-list.latest ${WORKDIR}/compat32-list.installed
fi
if [ -s ${WORKDIR}/compat32-list.new ] ; then
echo "(DEBUG) including new mutlilib packages : $(cat ${WORKDIR}/compat32-list.new | tr "\n" " ") "
LIST=""
for PKG in $(< ${WORKDIR}/compat32-list.new) ; do
LIST="$LIST $(grep " ${PKG} " $WORKDIR/pkglist | cut -f6,8 -d" " --output-delimiter=".")"
done
fi
fi
Quote:
Originally Posted by zerouno
Tipically a compat32 library NEED the 64bit conterpart becouse the compat32 packages install only the usr/lib/ files and few other.
the qt original package contains many file in /usr/share and /etc not presents in qt-compat32.
I dont tried, but I doubt that the qt-compat32 work fine without that files.
I tried. I removed 64-bit "qt" and google-earth works. It spits some error but I'm not sure whether it's because 64-bit qt is not installed :
Code:
$ google-earth
[1112/185237:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses()
[1112/185238:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
[1112/185238:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.