slackpkg vs. third-party package repository

55020 · 11-06-2013, 07:13 AM

Quote:

Originally Posted by zerouno

In practice I have, in my system, a series of packages that are newer than those found in the configured repositories

Me too, but slackpkg+ solves the problem for me! I put them in their own local directory MIRRORPLUS['dirty']=dir://<path> with PKGS_PRIORITY=( dirty:.* ... )

zerouno · 11-06-2013, 07:34 AM

Quote:

Originally Posted by kikinovak

@zerouno: slackpkg+ is just perfect as is. As far as I'm concerned

nothing is perfect

, and all is improved.

Quote:

Anyway, I've added a big THANK YOU note in my repository (http://www.microlinux.fr/slackware/README.txt).

Only today I see your PM, but google notified me your readme

Quote:

The only thing that's left to do is correct a few typos, but that's all.

already done; thanks to idlemoor. I will add fix in next repackaging (rc4 or stable??

)

Quote:

Originally Posted by 55020

MIRRORPLUS['dirty']=dir://<path> with PKGS_PRIORITY=( dirty:.* ... )

This is what I call a 'dynamic blacklist'. But this do not solve the problem. If a repository add an upgraded package, slackpkg+ will not show it but the only in 'dirty' repository.

Another feature to add should be a method to allow to show in dialog the packages presents in the all repository, not only packages as in the PRIORITY list.
For now you can to see the hidden packages (becouse not the first in PRIORITY list) only by 'slackpkg search'.

55020 · 11-06-2013, 07:50 AM

Quote:

Originally Posted by zerouno

But this do not solve the problem. If a repository add an upgraded package, slackpkg+ will not show it but the only in 'dirty' repository.

Ahhh... yes of course you are right. Apparently I'm stupid today. Still, bumping any thread that's not about systemd is a good thing

zerouno · 11-07-2013, 05:37 PM

slackware 14.1 is released.
Unfortunatley slackpkg+ cannot be released before next mondey.

(i've not a computer in this long weekend; It's a tragedy... )

mRgOBLIN · 11-08-2013, 04:51 AM

zerouno I had a crack at something like this a while back. Uses "weighting" and seems to work reasonably well.
I agree with others in that this is not really a required feature for slackpkg+ but it might be fun to play with anyway.

Code:

#!/usr/bin/gawk -f
{

# Keep origin values
first = $1
second = $2

# Tell us if they are the same and move on to the next record
if ( first == second ) { print first " is equal to " second ;next }

# Replace underscores with dots 
sub(/_/, ".", $1)
sub(/_/, ".", $2)

# If no rc in first field and rc is in second then weight accordingly 
if ( $1 !~ /rc[[:digit:]]*/ && $2 ~ /rc[[:digit:]]*/ ) $2 = ($2 - .02)

# and the other way around
if ( $1 ~ /rc[[:digit:]]*/ && $2 !~ /rc[[:digit:]]*/ ) $1 = ($1 - .02)

if ( $1 !~ /beta[[:digit:]]*/ && $2 ~ /beta[[:digit:]]*/ ) $2 = ($2 - .03)
if ( $1 ~ /beta[[:digit:]]*/ && $2 !~ /beta[[:digit:]]*/ ) $1 = ($1 - .03)
if ( $1 !~ /alpha[[:digit:]]*/ && $2 ~ /alpha[[:digit:]]*/ ) $2 = ($2 - .04)
if ( $1 ~ /alpha[[:digit:]]*/ && $2 !~ /alpha[[:digit:]]*/ ) $1 = ($1 - .04)

# If dotted split into array and compare each element
# We go left to right so the first largest or smallest 
# comparison should give the correct result

if ( /^[[:digit:]]+\.([[:digit:]]+\.)+[[:digit:]]/ ) {
    split($1, ver1, ".")
    split($2, ver2, ".")
        for (i=1; ver1[i]; i++) {
        ver1[i] = ( ver1[i] +0 ) ;  ver2[i] = ( ver2[i] +0 )
        if ( ver1[i] < ver2[i] ) { print first " is smaller than " second ;next }
        if ( ver1[i] > ver2[i] ) { print first " is larger than " second ;next }
        }
    next
}

# Print the results
if ($1 > $2) print first " is larger than " second
if ($1 < $2 ) print first " is Smaller than " second
}

jtsn · 11-08-2013, 07:58 AM

mRgOBLIN, your "weighting" doesn't work:

Code:

linux-3.4.68 is Smaller than linux-3.9.11

And that's not true, Linux 3.4.68 was released on Nov 2013 while linux-3.9.11 was released on July 2013. So Linux 3.9.11 clearly is "smaller" (as in much older).

BTW: The purpose of slackpkg (the original) is to compare the current installation to the reference image (the fully patched Slackware distribution) and display the differences. Packages with a "newer/better/whatever"version (installed from different sources) count as differences too, because they mave have bugs or security vulnerabilities not present in the fully patched Slackware distribution and the purpose of slackpkg is to upgrade the system to the official known-good state.

So skipping over a package, because its version number is higher, clearly is an error. It leaves a package on the system, that doesn't belong there or maybe even harmful.

Example: Slackware 14.0 is available with LTS kernel 3.2.29. Now a security vulnerability is discovered and Slackware is patched to kernel 3.2.45. But the user upgraded to kernel 3.3.8, which is EOL and may have the vulnerability, too. Now a slackpkg+ with this version "weighting" would skip over kernel 3.3.8, because it's "newer", while in reality it's not. The tool can't tell the difference, because it doesn't know anything about Linux release cycles... Any software project with branching confuses these primitive version comparators. And trying to detect "alpha", "beta" and other strings doesn't change anything about it.

If a tool is called slackpkg+ the basic semantics should be the same, otherwise it causes confusion.

solarfields · 11-08-2013, 08:39 AM

Quote:

It's a tragedy...

hold on man!

mRgOBLIN · 11-08-2013, 12:59 PM

Quote:

Originally Posted by jtsn

mRgOBLIN, your "weighting" doesn't work:

Code:

linux-3.4.68 is Smaller than linux-3.9.11

And that's not true, Linux 3.4.68 was released on Nov 2013 while linux-3.9.11 was released on July 2013. So Linux 3.9.11 clearly is "smaller" (as in much older).

But it would still be considered an "upgrade" from the 3.4 branch to the 3.9 branch.

Quote:

Originally Posted by jtsn

BTW: The purpose of slackpkg (the original) is to compare the current installation to the reference image (the fully patched Slackware distribution) and display the differences. Packages with a "newer/better/whatever"version (installed from different sources) count as differences too, because they mave have bugs or security vulnerabilities not present in the fully patched Slackware distribution and the purpose of slackpkg is to upgrade the system to the official known-good state.

So skipping over a package, because its version number is higher, clearly is an error. It leaves a package on the system, that doesn't belong there or maybe even harmful.

Example: Slackware 14.0 is available with LTS kernel 3.2.29. Now a security vulnerability is discovered and Slackware is patched to kernel 3.2.45. But the user upgraded to kernel 3.3.8, which is EOL and may have the vulnerability, too. Now a slackpkg+ with this version "weighting" would skip over kernel 3.3.8, because it's "newer", while in reality it's not. The tool can't tell the difference, because it doesn't know anything about Linux release cycles... Any software project with branching confuses these primitive version comparators. And trying to detect "alpha", "beta" and other strings doesn't change anything about it.

If a tool is called slackpkg+ the basic semantics should be the same, otherwise it causes confusion.

No arguments from me here... and if you notice I said as much when I posted the code. I'd hate the idea of the package management deciding what is an "upgrade"

When I wrote this it was relevant within our own project as we had control of the version number format and I'd also modified it a little to give as an example when someone asked me how I'd go about detecting version up/downgrades. Now pasted here more for entertainment than anything else 8)

phenixia2003 · 11-08-2013, 02:11 PM

Hello,

I have a new patch for slackpkg+ 1.0rc3.

1. I guess it is useful to have the slackpkg version number printed somewhere when running slackpkg. So, I added it right after slackpkg version. Note, this only works when DIALOG=on. Here is a screenshot.

2. For compat32pkg 1.5 I have implemented a feature that I called the triggers. To summarize, this is a mechanism that allows user to execute an action (print a message, execute a command) in response to an event.

I (partially) added this feature into slackpkg+ so that user can map messages to events. When an event occurs, the message associated to it, if any, is printed, in a dialog when "DIALOG=on", on the standard output otherwise.

In slackpkg+ the following events are supported : on_install, on_upgrade and on_remove

For instance, if you want to print a reminder to reinstall the nvidia/amd driver each time the packages mesa, mesa-compat32, xorg-server are updated, you simply have to add the following into your /etc/slackpkg/slackpkgplus.conf :

Code:

NOTIFYMSG[on_upgrade@mesa.*,xorg-server]="The nvidia/amd driver need to be reinstalled !"

When DIALOG=on, the messages are printed like that, otherwise the messages are printed like this.

In attachment, you will find the following patches :

slackpkgplus_1.0rc3.patch :
the main patch for slackpkg+ 1.0rc3
slackpkgplus.x86.sample_1.0rc3.patch and slackpkgplus.x86_64.sample_1.0rc3.patch :
these patchs add documentation for the new variable NOTIFYMSG and include a message for the events "on_install@mesa.*,xorg-server" and "on_upgrade@mesa.*,xorg-server"

Hope this helps.

--
Seb

re_nelson · 11-08-2013, 02:16 PM

Quote:

Originally Posted by Alien Bob

[...]Just like the lack of dependency checks is a strength, not a weakness.

Eric (and anyone else):

I've seen that statement and variants thereof numerous times over the years and would appreciate any further elaboration on it. My primary working system is Linux from Scratch, as it has been for a decade or so, and Slackware is a close second in terms of time spent while computing. As a result, dependency checking and even keeping track of packages is something I'm accustomed to doing manually. So as someone who essentially rolls my own distro, I can see that point and don't need any persuasion.

But for individuals new to Slackware, coming from systems using yum, pacman, apt and others, how is the absence of dependency checking
beneficial? This is not asked in an argumentative manner but only to get some points that buttress the assertion, especially for some of my colleagues who perceive dependency resolution as a "must have" feature.

Didier Spaier · 11-08-2013, 03:18 PM

@ re_nelson: I couldn't say it better than ruario already did.

re_nelson · 11-08-2013, 03:30 PM

Quote:

Originally Posted by Didier Spaier

@ re_nelson: I couldn't say it better than ruario already did.

Thank you! That's a very interesting read on the subject and the followup give and take in the comments section is worthwhile reading.

Perhaps the one thing that most appeals to me concerning the Slackware philosophy is that there's not a split between the between the base package and the development package. I see this as an atomic item and never understood the division into the "-dev" or "-devel" packages. Of course, that may stem from my bias as a programmer and having been accustomed to building nearly everything on my primary system from source. IMHO, both Gentoo and FreeBSD get this aspect right in portage and ports.

phenixia2003 · 11-09-2013, 12:19 PM

Hello,

I should read this thread more carefully, I didn't noticed this message until now

Quote:

Originally Posted by zerouno

I want to add that script in /usr/doc/slackpkg+-*

the idea is that isn't really explicit how to setup slackpkg+ to add multilib support.

I tested it only a few (I do not use the alienbob multilib

).

/usr/doc/slackpkg+-*/setupmultilib.sh

There's a typo in the section below :

Code:

  echo "Do you want install then multilib now? (y/N)"
  read ANS
  if [ "$ANS" == "y" -o "$ANS" == "Y" ];then
    slackpkg update
    slackpkg upgrade multilib
    slackpkg install multilib
    echo "Multilib installed"
  else
    echo "To install multilib type:"
    echo "# slackpkg update"
    echo "# slackpkg upgrade gcc glibc"
    echo "# slackpkg remove multilib"
  fi

This should be :

Code:

  echo "# slackpkg install multilib"

About the section below :

Code:

  if [ "$SVER" == "current" ];then
    echo "Remember... When you see NEW packages with 'slackpkg install-new' command,"
    echo "you may need to install the related multilib package"
  fi

For better 32-bit support, packages are added to the multilib by Eric when required, but this is not limited to the -current tree. Furthermore, When new packages are added to the multilib, user has simply to run the command 'slackpkg update && slackpkg install multilib' to install them.

I guess, that you can add a message to explain this, for any version of slackware. This message could also be printed each time the 32-bit layer is updated, using the new feature I posted yesterday. For this, you simply have to add this declaration into the /etc/slackpkg/slackpkgplus.conf :

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"

In attachment you will find a screenshot to illustrate this.

Hope this helps.

--
SeB

zerouno · 11-09-2013, 06:15 PM

many typos are corrected in the current github version (that will be the 1.0 stable in two days).

The 1.0 version is freezed and the 1.0.x should contains only bugfix. For new feature I'm preparing a development tree, not only for test the new functions but to decide IF add it (we can decide what break the slackware approach, that I slackpkg+ should preserve, and what do not break it)

phenixia2003 · 11-10-2013, 06:11 AM

Hello,

Quote:

Originally Posted by zerouno

many typos are corrected in the current github version (that will be the 1.0 stable in two days).

But not the typo I pointed out.

Quote:

Originally Posted by zerouno

The 1.0 version is freezed and the 1.0.x should contains only bugfix.

Is this a joke ? slackpkg+ is definitely not libreoffice ...

Quote:

Originally Posted by zerouno

For new feature I'm preparing a development tree, not only for test the new functions but to decide IF add it (we can decide what break the slackware approach, that I slackpkg+ should preserve, and what do not break it)

When I publish a patch here, this is to give to the users base a chance to test it, and to report any problem. Moreover, I conscientiously tested the last patch I sent, it works well, and I would be really surprised that someone tells it breaks slackware philosophy. This is a simple and efficiently way to notify the users when required. Furthermore, this feature can be easily disabled by removing (or by commenting out) the occurences of NOTIFYMSG in slackpkgplus.conf

To finish this post, I took the time to read other posts here, and I'm really disapointed that people are thinking there's only zerouno behind slackpkg+. The last patch I sent was and will be the last. Sorry, but I'm out of this.

--
SeB