ConnochaetOS author here. I just wanted to clarify some things.

ConnochaetOS is a Slackware/Salix based "fully free" GNU/Linux Distribution, following the Free System Distribution Guidelines (GNU FSDG).

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.

Which Packages are being deleted is documented in https://connochaetos.org/slack-n-fre...list-salix.txt and https://connochaetos.org/slack-n-fre...-slackware.txt

The slack-n-free repo at https://connochaetos.org/slack-n-fre...k-n-free-14.1/ contains modified and additional packages, e. g. the Linux-Libre kernel and "freed" versions of the Mozilla programs.

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:

1. As I see it slackpkg+ is not stable enough to be included by default in a stable distribution release.
2. 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!

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.

You have also a technical reason. Try that:
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.

Hi zerouno,

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


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.

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

Attached Files

slackpkg+bastest.txt (29.0 KB, 8 views)

Maybe this:

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

Attached Files

	slackpkg+bash-readable-part1.txt (242.4 KB, 13 views)
	slackpkg+bash-readable-part2.txt (200.1 KB, 21 views)

Do you use sudo?

I obtain the problem when I use sudo and in sudoers there is not the NOPASSWD directive.

Do you confirm?

try that:

Edit /usr/libexec/slackpkg/functions.d/slackpkgplus.sh

find
substitute with

@zerouno: I do not know what the problem is, but why replacing a character class by an equivalent range expression would lead to a different result?

@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?

Happy New Year.

Hello,

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

--
SeB

1 members found this post helpful.