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.
The repo of Salix consists of Salix own repo and a Slackware repo (plus dependency information). This are the repos I do sync and then modify. The modification is necessary in order to follow the FSDG, because there are some packages which are not free according to this guidelines. Note that the modification do not concern the packages itself, instead packages which are not FSDG-free are simply deleted from the repo and then PACKAGES.TXT and CHECKSUMS.md5 are being re-created. Because of this the CHECKSUMS.md5 file differs from the original repo, which is why it is signed with my GPG key. The single original Slackware packages are still signed with the original GPG key.
Also note that ConnochaetOS, as SalixOS does, uses slapt-get as "native" package management tool. I added the possibility to use slackpkg+ as an additional possibility just a fews days ago, after I tested it. But I do think about a ConnochaetOS "current" repo, based on Slackware-current with slackpkg+ as the only package management tool.
I am considering shipping slackpkg+ as packages management tool in next Slint version too.
But I am a bit worried because:
As I see it slackpkg+ is not stable enough to be included by default in a stable distribution release.
It includes features that are not so useful IMHO, like managing local packages or remote "custom" repositories (we have already tools to do that), but make it harder to grasp its working and could introduce bugs.
So I am wondering: would it be possible to have a "stable" branch with less but heavily tested features and a "devel" or "current" branch?
I understand that we were leaded to the current situation due to slackpkg+ history: zerouno first wrote it with a limited scope and limited use cases in mind, but as this tool proved to be very useful, overtime many people asked for more features and an extended scope.
Maybe now is a good time to stabilize things a bit.
One thing could be to write specs for the "stable" version, voluntarily limited but that could be extended in the "current" or "devel" branch. I am ready to participate in writing down these limited specs with anyone interested.
What do you think, everybody? Especially zerouno and phenixia2003, of course!
Last edited by Didier Spaier; 01-01-2016 at 06:30 AM.
Reason: Typo fix
Didier, what do you mean by "remote "custom" repositories (we have already tools to do that)"? Slackpkg+ was written with the express purpose of supporting remote 3rd party repositories and not just the official Slackware repositories. Are you referring to the ConnochaetOS repository which is in fact 3 repositories?
Didier, what do you mean by "remote "custom" repositories (we have already tools to do that)"? Slackpkg+ was written with the express purpose of supporting remote 3rd party repositories and not just the official Slackware repositories. Are you referring to the ConnochaetOS repository which is in fact 3 repositories?
No and I should have been more clear, sorry.
I had in mind the possibility through slackpkg+ to manage (install/upgrade/reinstall) remote packages without metadata, as stated in the README
Hello haary.
Thankyou for your repository. I have studied your work and I have already added it to repositories.txt in the development tree.
ConnochaetOS is slackpkg+ compliant.
About /etc/slackpkg/mirrors I think that this file should contains only official reporitories or an exact mirror.
slackpkg+ does not manage dependencies, so there is not a value added to replicate the official repository and remove packages from it.
You know that if you put PKGS_PRIORITY=( slacknfree ), you do not need to remove packages from slackware repository.
Having in a repository a package signed with the key of another repository (even if is the official packages and the official signature), may generate confusion. Also may generate doubt to users that see the official repository partially populated.
the installation of aaa_base will fail becouse there is not the slackware GPG-KEY imported.
If you use slapt-get you MUST do that becouse you need to add dependencies. But slackpkg is an official tool and slackpkg+ try to diverge less than possible from slackpkg.
However I used your slackware modified repository just as an example to study what security implications may bird on other repository if this problem will be not fixed (you copied slackware official packages, someone can copy other non-slackware packages).
Another think that I noticed in your repository, is that some package has not the $TAG after $BUILD version; that can generate confusion, but is a your choice. And there is a package NON SLACKARE compliant:
kernel-debian-source-3.16-7_ckt11_1_deb8u4.txz
it has no $ARCH.
installpkg should accept it; slapt-get I don't know; slackpkg+ may fail or skip it (but I have not tested it).
"kernel-debian-source-3.16-7_ckt11_1_deb8u4.txz" is a non Slackware package name. If it is part of a repository then that repository is not slackpkg compatible.
Thankyou for your repository. I have studied your work and I have already added it to repositories.txt in the development tree.
ConnochaetOS is slackpkg+ compliant.
Thanks.
Quote:
Originally Posted by zerouno
About /etc/slackpkg/mirrors I think that this file should contains only official reporitories or an exact mirror.
slackpkg+ does not manage dependencies, so there is not a value added to replicate the official repository and remove packages from it.
You know that if you put PKGS_PRIORITY=( slacknfree ), you do not need to remove packages from slackware repository.
Modifying the repo is not so much a technical but a political requirement by the Free System Distribution Guidelines, see License Rules. A FSDG-compliant distro is required not to refer to third-party repositories that are not committed to only including free software.
The reason is: Even if the slack-n-free repo is listed in the configuration file with a higher priority, users could still learn about non-free packages in the official Slackware repo and install them without knowing that the package contains non-free code. This is also the reason why Debian isn't at FSFs Free Distro list, because they refer to the non-free repo.
The whole point of a fully free distro is to guarantee, that absolutely no non-free program will be installed on your system using systems tools and repositories. This does, of course, not prevent that you can add other repos manually or install non-free code from somewhere else (preventing that would contradict the spirit of free software).
Quote:
Originally Posted by zerouno
However I used your slackware modified repository just as an example to study what security implications may bird on other repository if this problem will be not fixed (you copied slackware official packages, someone can copy other non-slackware packages).
You're right. Is there a secure way to handle two different GPG-KEY files - one for packages, other for metadata like CHECKSUMS.md5? The only other solution would be, that I sign all packages, including the original Slackware packages with my GPG key.
Quote:
Another think that I noticed in your repository, is that some package has not the $TAG after $BUILD version; that can generate confusion, but is a your choice. And there is a package NON SLACKARE compliant:
kernel-debian-source-3.16-7_ckt11_1_deb8u4.txz
it has no $ARCH.
Thanks for the hint, I will correct it with the next update of this package.
@zerouno when I attempt to redirect the output to a .txt file it is mostly unreadable text garbage, I'm probably doing it wrong. I've used the following command
bash -x slackpkg install-new > /home/brian/Documents/slackpkg+bashout.txt
If I simply let it scroll in Konsole, or XFCE terminal or XTERM, the buffer is overun and only part of the file is available to scroll back and paste to a document.
Open for suggestions on things to grep and output, or how to properly redirect the output so it is the readable text?
Thanks, BrianA_MN
Last edited by bamunds; 12-31-2015 at 01:25 PM.
Reason: added output available from buffer.
@Diantre Thanks for the education, I'll have to keep that one in my tool bag.
@zerouno Attached is a readable files (2 parts because of size) of the data that you requested.
Last edited by bamunds; 12-31-2015 at 04:11 PM.
Reason: file broken into two parts due to size limits of LQ
@zerouno
Yes I can confirm that I use a sudoers file and do not use the NOPASSWD parameter. Instead if I'm going to do a substantial number of root required activity over more time that is set under sudo for users, I use the "sudo su -". I was using sudo su - because when I tried "su -" it wouldn't allow me to enter the password. But today I've tried both methods and it is working. So I wonder if this issue was because of my use of "sudo su -"?
If login in usermode "sudo slackpkg install-new", then enter sudo password the grep error messages DON'T occur
If login as root then "sudo slackpkg install-new" the grep error messages DON'T occur
If login in usermode "sudo su -" then once in root# sudo slackpkg install-new enter sudo password the grep error message WILL occur
I see you've posted a fix, but wanted you to know the specific situations where it occurs before the the patch.
The patch corrects the problem so the error messsages don't occur when using "sudo su -"
I'm sorry that I didn't connect this with the implementation of sudo on the PC. That was implemented a month ago when I was getting pm-utils functioning in fvwm-themes.
Thank you so much for the patch. Is this something unique that I'll need to maintain each time you re-issue slackpkgplus?
I've reproduced the error encountered by bamunds and I've tried what zerouno has suggested, but it does not work all the time for me, and more precisely when the user credential are reset :
Code:
$ sudo --remove-timestamp
$ sudo su -
password:
$ sudo slackpkg install-new
slackpkg install-new
Looking for NEW packages to install. Please wait... grep: write error
grep: write error
grep: write error
grep: write error
grep: write error: Broken pipe
grep: write error
[snip]
grep: write error
DONE
No packages match the pattern for install. Try:
/usr/sbin/slackpkg upgrade|reinstall
However, the issue seems linked to the last grep in the line pointed out by zerouno. Indeed, if this line is broken in two parts (as below), the issue disappears :
$ sudo --remove-timestamp
$ sudo su -
password:
$ sudo slackpkg install-new
slackpkg install-new
Looking for NEW packages to install. Please wait... DONE
No packages match the pattern for install. Try:
/usr/sbin/slackpkg upgrade|reinstall
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.