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.
In my office I have a build box for 32-bit as well as 64-bit packages, that I use when performing installations on client machines. What I normally do is burn these to a CD-Rom and also copy them to a USB stick, so once I've installed a vanilla Slackware system, I can easily add these (currently 170) packages.
Now I wonder if there is a way of doing the following:
Put all my packages on my HTTP and/or FTP mirror
Configure slackpkg to use this mirror
Use slackpkg transparently from there on, e. g. 'slackpkg install xscreensaver' would fetch the package from an official Slackware mirror, but 'slackpkg install lame' would use mine.
My packages replace the odd vanilla Slackware package, things like vte or MPlayer. And they are all tagged "_microlinux" so there's no mistake.
Is there a chance for this to succeed, or is this doomed from the start?
Unfortunately that is not going to work. Slackpkg only works with official packages. The program reads the meta-data files in the Slackware tree (ChangeLog.TXT, PACKAGES.TXT, CHECKSUMS.MD5 etc) and from that, it determines the list of packages which make up a release. You can add to the tree what you want, but it won't be picked up by slackpkg.
Unfortunately that is not going to work. Slackpkg only works with official packages. The program reads the meta-data files in the Slackware tree (ChangeLog.TXT, PACKAGES.TXT, CHECKSUMS.MD5 etc) and from that, it determines the list of packages which make up a release. You can add to the tree what you want, but it won't be picked up by slackpkg.
Thanks for the advice, Eric. Well, KISS as usual (CD-Rom, USB disk, manual download) will do very well too.
On a side note: I *think* my Slackware-based Microlinux Enterprise Desktop must be quite a success. When I first installed our school's network back in 2010, using a beefed-up CentOS 5.3, the students (15 to 20 years old "difficult" kids) commented with words like "lame", "boring", etc. Last year I had a mix of Slackware 13.37 and a hand-built KDE 4.6.5 with many tweaks also. The average student worked on it OK, but described the desktop as "pretty lame", "not as good as Windows" (the latter probably because there were still no games). But this year, my personal mix of Slackware 13.37 plus beefed-up Xfce 4.8 with some nice artwork plus many apps seemed to have changed the critic's voice. Since the first week of september, I only get remarks like "Hey, I like this new system" and "This new system is soooo easy to work with" or "Geee it's really fast". I think I'm on the right track here. (Or maybe I'm just more popular at the school, and the system is still crap )
It presents some problem with:
- repositories that does not contains a MANIFEST.bz2 (you can obtain a warning, non fatal, in slackpkg update)
- repositories that contains multiple packages with the same name (i.e. repository that contains both 32&64 bit packages or 13.1&13.37¤t version of the same package); slackpkg use only the first package in list and skip all other.
I've configured only slacky.eu (64bit) and alienbob repository, but you can change and add repositories from slackpkgplus.conf
You can obtains a large repositories list from http://slakfinder.org
I finally had time to look at this. I think there is potential here, but some things can be improved if slackpkg itself gets some updates.
In any case, I changed one line in /usr/libexec/slackpkg/functions.d/slackpkgplus.sh and that is the priority of the repositories. In the original file, the non-Slackware repositories have lowest priority, which is not what I want. If I have a package in a non-Slackware repository (say, glibc's multilib version) I want that to have higher priority than the Slackware package so that the Slackware package can never overwrite the multilib/custom package...
I am now able to manage updates for Slackware packages, my own repository packages and the multilib packages.
The /etc/slackpkg/blacklist file no longer blacklists my packages:
Code:
# You can blacklist using regular expressions.
#
# Don't use *full* regex here, because all of the following
# will be checked for the regex: series, name, version, arch,
# build and fullname.
#
# This one will blacklist all SBo packages:
[0-9]+_SBo
#[0-9]+compat32
#[0-9]+alien
Of course, the slackpkg functionality that still only works with Slackware repositories is slackpkg's "install-new" but I am able to use "upgrade-all", "search", "file-search" and "info" functions with my own repositories. Cool!
Of course I needed to adapt my repository layout for this to work. That is why for my SlackBuilds repository you see a new URL location with "sbrepos/<slackversion>/<architecture>" instead of the old generic "slackbuilds" because I wanted to leave my original repository directory structure intact. Basically I created a "shadow-repository" using hard-links so that it almost does not use any disk space. The multilib repository now has some additional files which will ebable you to add the URL for a specific Slackware version. See the above example.
Not sure whether this is of interest to anyone but it's a simple tool I call 'slacklist' that I use to keep my system in step with slackware-current. It's not as sophisticated as slackpkg and is designed only to work with local sources of packages, but it does handle combining multiple sources of packages together before comparing them to what is on the existing system.
As an example, if you keep your local copy of slackware64-current in /local/slackware64-current and your locally built packages in /local/packages then to keep things in sync you could use something along the lines of
The starting idea for slackpkg+ was to add the only slacky repository (where I'm a contributor), and one-only; in effect the original name was slackypkg next renamed slackpkg+sl, so I wrote a VERY DRAFT plugin.
Only after posting in this thread I modified (aka complete rewrite) the plugin to add multiple repositories but I wrote it in a very short time , so it is NOT a mature plugin.
In effect a large problem was with your repository becouse it contains multiple version of the same packages. I was looking for a solution. The same problem was for the slakfinder, for your repository and all other listed in 'mixed' section. The problem was solved in slakfinder 2.0 (never released ) with a method "try to guess", not applicable in slackpkg+. So thanks for reorganize your repository (that, in effect, is the only definable 'ufficial'); I will modify the slakfinder in some days.
I paused to devel slackpkg+ for two reasons. The first is the time that I can spent. The second is becouse to improve really the tool and to add very good feature I need to patch some slackpkg file and I don't want to do that.
Returning to the starting idea, the main assumption was that slackpkg+ was to be used to add packages not presents in slackware main repository, so slackpkg+ 0.2 does not allow to overwrite slackware packages with thirdy part packages.
Who use the multilib repository want implicitly override ALL original packages with packages presents in that repository.
But the problem begins with repositories containing both packages already presents in slackware and packages new.
For example, your restricted_repository contains mplayer and vlc. If I add that repository only for vlc, and put that repository as first priority, slackpkg upgrade-all will substitute the mplayer slackware packages with your mplayer, but I want only to add (and update) vlc.
That problem may be partially solved allowing to configure the order in slackpkgplus.conf so the user can choice
( multilib patches %PKGMAIN extra pasture testing restricted sbrepos )
But the problem continue (with no solution without modify the core&structure of slackpkg) when you have two thirdy party repository containing the same package. For example, both restricted_repository and slacky repository contains the openjdk and apache-ant packages. If I want to install your openjdk I must put your repository in priority; next if I want to install slacky apache-ant, I change the order putting slacky repository in priority. Well; now I type slackpkg upgrade-all and slackpkg ask me to substitute your openjdk with slacky openjdk.
IHMO there are only two solution; both require a structural slackpkg change.
1) at moment the only way to know which repository contains the packages that I installed is the suffix (sl,alien,sbo...); if I'd installed openjdk-....-1alien packages, slackpkg upgrade-all should search only for openjdk-*-*-*alien unless the user specify a parameter '--all' or similar. This open many other problems
2) slackpkg should allow to show multiple packages with the same name in list. This, also, open many other problems
but this means to "write a new (another??) remote repository manager"
Other package manager have similar problem.
slackyd (ufficial tool for slacky repository) have in the configurarion file: "upgrade_replacing_official = yes"
slapt-get allow the suffix ":OFFICIAL" ":PREFERRED" ":CUSTOM"
Regarding the link instead download packages for local repositories, the slackpkg+ is native for remote repositories. I don't known how many people download the entire alien/sbo/slacky/... repository on its pc.
For the .asc support, I remove it for semplicity and also becouse not all thirdy party repository support it.
If you know solutions or have some idea... you are welcome .
Of course, the slackpkg functionality that still only works with Slackware repositories is slackpkg's "install-new" but I am able to use "upgrade-all", "search", "file-search" and "info" functions with my own repositories. Cool!
search and file-search are buggy. I sent a patch to fix it at slackpkg's website.
Quote:
Originally Posted by Alien Bob
Of course I needed to adapt my repository layout for this to work. That is why for my SlackBuilds repository you see a new URL location with "sbrepos/<slackversion>/<architecture>" instead of the old generic "slackbuilds" because I wanted to leave my original repository directory structure intact. Basically I created a "shadow-repository" using hard-links so that it almost does not use any disk space. The multilib repository now has some additional files which will ebable you to add the URL for a specific Slackware version. See the above example.
Excuse me but I don't understand why you try to add support for the multilib in a tool which was not designed to manage this. If you think that slackpkg is a better tool to manage the multilib than compat32pkg/multilibpkg (is there something wrong with these tools I should know ?), then I guess it would be better to directly integrate the multilib in Slackware64.
Excuse me but I don't understand why you try to add support for the multilib in a tool which was not designed to manage this. If you think that slackpkg is a better tool to manage the multilib than compat32pkg/multilibpkg (is there something wrong with these tools I should know ?), then I guess it would be better to directly integrate the multilib in Slackware64.
I am not attacking your ompat32pkg/multilibpkg tool. I am showing how slackpkg can be expanded with custom functionality. It was designed to be able to do this.
In the end, people are free to use whatever tool they feel most comfortable with.
But the problem continue (with no solution without modify the core&structure of slackpkg) when you have two thirdy party repository containing the same package. For example, both restricted_repository and slacky repository contains the openjdk and apache-ant packages. If I want to install your openjdk I must put your repository in priority; next if I want to install slacky apache-ant, I change the order putting slacky repository in priority. Well; now I type slackpkg upgrade-all and slackpkg ask me to substitute your openjdk with slacky openjdk.
Just an idea, which does not solve the problem related to "upgrade-all", but allows the user to install (or upgrade) a package from a given repository without to have to manually change the variable PRIORITY :
With this extension, to install vlc from alien repository, user would have to issue the command :
Code:
$ slackpkg install alienbob:vlc
And, to install openjdk from slacky repository, he will issue that :
Code:
$ slackpkg install slacky:openjdk
To upgrade the installed apache-ant (from slacky) to the latest version, user will issue the command :
Code:
$ slackpkg upgrade slacky:apache-ant
To provide these features, you only need to add the code below after yours in slackpkgplus.sh :
Code:
if [ "$CMD" == "install" ] || [ "$CMD" == "upgrade" ] ; then
NEWINPUTLIST=""
for pref in $INPUTLIST ; do
if echo "$pref" | grep -q "[a-zA-Z0-9]\+[:][a-zA-Z0-9]\+" ; then
repository=$(echo "$pref" | cut -f1 -d":")
package=$(echo "$pref" | cut -f2- -d":")
PRIORITY=( slackpkgplus_${repository} ${PRIORITY[*]} )
else
package=$pref
fi
NEWINPUTLIST="$NEWINPUTLIST $package"
done
INPUTLIST=$NEWINPUTLIST
fi
IMPORTANT NOTES:
1. because the granularity of PRIORITY is too low, this can lead to some trouble when trying to install different packages from different repository at the same time. For instance :
When (1) is executed, vlc from alienbob and openjdk from slacky could be installed. But, in the case of (2), vlc and openjdk will be taken from alienbob repository.
As said above, this is because the granularity of PRIORITY is too low, it only allow to give priority to directory, not package. Note that compat32pkg comes with something like "PRIORITY" (called PKGS_PRECEDENCE_ORDER) which allows higher granularity. I guess the function FilterByPrecedenceOrder() from compat32pkg could be adapted to slackpkg+, but I don't really have the time to look at this.
2. The code above accepts only repositories with letters and/or digit (ie line echo "$pref" | grep -q ...). Don't hesitate to improve this.
Hope this help.
--
SeB
Last edited by phenixia2003; 03-18-2013 at 05:39 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
at 
, so it is NOT a mature plugin.
) with a method "try to guess", not applicable in slackpkg+. So thanks for reorganize your repository (that, in effect, is the only definable 'ufficial'); I will modify the slakfinder in some days.
