akimmet, your posts are always helpful. I have thought about this myself and come to the present conclusion that I see nothing wrong with using slackpkg+ since it just does what I would do anyway, just quicker. I have retained the knowledge of how to do things manually and still build packages manually [for 'fun'] when I feel like it, and I install packages manually.

One thing confuses me, can you please elaborate on this:

Do you mean that sometimes slackpkg can install a second version of a package [i.e. leave the presently installed one and install a new one]? And if so, why is this the case?

Slackpkg won't do that, but installpkg will. Once there are two versions of the same package installed, slackpkg will refuse to work again until one is removed or blacklisted. If I am installing a package manually, I prefer to use upgradepkg instead to prevent myself from installing something twice by accident.

2 members found this post helpful.

I am slightly confused about something. When running slackpkg update, it gives me the following output [attached]. I thought the multilib libraries were just some of the gcc and glibc's. Should I upgrade these other packages too or leave them?

Attached Thumbnails

 

Technically "multilib" is just gcc and glibc. The rest of these are "compat32", which are 32bit packages that have their directories tweaked to ensure they can install on a 64bit system without overwriting the 64bit package.

They aren't multilib, just a repackaging of a 32bit package to install on a 64bit system that is multilib enabled.

1 members found this post helpful.

Thanks bass, so it's OK to install them. Well, they came from Eric's repo so they would be fine I'm sure, I just didn't understand what they were.

I did not saw that topic...


thanks all to share your configurations and experience.
I see that no one are using CACHEUPDATE=on; I like it (save many time in the slackpkg update and give a most compact output), and I like to know what other users think about it.

Someone are using or tested the development version? it add some feature and change some default setting.


My configuration:
The SBOURL is new on the development release (used only in the 'slackpkg search'; it will not install/download nothing; just notify you if the package is available on SBo)
The 'export TERSE=1' is not a new feature of slackpkg+ but a new feature of pkgtools on slackware current

Unfortunately I have too few time to develop it, but I would to know which feature you would add/modify/remove in next release stable.

1 members found this post helpful.

Yeah, these are typically the 32bit libraries that a lot of 32bit programs would rely on. You get them by running covertpkg-compat32 on regular 32bit programs. It will make sure any 32bit binaries don't overwrite the standard 64bit binaries along with a few other tweaks.

1 members found this post helpful.

I'm using "CACHEUPDATE=on". I appreciate very much this feature. It saves time during the update process especially when there are repositories with few or no update like my repositories 'restricted' and 'slackpkgplus' (few updates) or 'mled' and 'extras' repositories (no update as the Microlinux project is now frozen).

Hello,

Is there any way to configure Ponce repo on slackpkg+?

I never figured out how to enable it.

Thanks

good luck with it, just be sure to read the README.txt in the repository directory, in particular the part where it says that use with any package manager is *UNSUPPORTED*

This made me discover an issue about Slint in http://slakfinder.org/slackpkg+/src/repositories.txt. I see there:Actually the Slint repositories are:
http://slackware.uk/slint/i586/slint-14.2/ # Consider it deprecated, although I still provide updates for security fixes
http://slackware.uk/slint/x86_64/slint-14.2/ # Idem
http://slackware.uk/slint/x86_64/slint-14.2.1/ # Actively maintained.

I do not advise to use slackpkg++ (not even slackpg, although it be available in Slint) with Slint repositories. If you want to install a Slint package in another distribution like Slackware better use installpkg or slapt-get and I can't guarantee that you won't encounter some incompatibility or missing dependency, depending of your system's content. I will help to sort issues if I can only then.

PS If you use installpkg, the dependencies will have to be handled manually. They are mentioned in PACKAGES.TXT and in the .dep files alongside the .txz ones in <repo>/slint and on Slackware, better have a full installation to begin with.

Hello akimmet and thank you for your response as I think it may be useful to expand on the cost/benefits, and again, especially for new users.

While I agree that sometimes, though not often for me, manually handling packages and their dependencies can qualify as "tedium", I consider tedium to be part of the cost of strong administration. It's very often tedious to write code and the process away from that level largely involves a sort of "dumbing it down" to make it convenient for non-coders to run and use. Every step away from code level is, by nature, a step away from understanding and control. I'm no "leet coder" (haven't worked in Assembly in well over a decade and never was all that potent) so I, too, already accept some level of loss in understanding and control, but I came to Slackware exactly because Mandrake package management broke my system and I couldn't even figure out exactly what caused that because I let it do the tedious work instead of me.

Granted automated package management has improved tremendously since 2000 but tedium is, or at the very least, can still be part of the responsibility of strong, informed administration. By managing manually I always know what went wrong, if and when something does (rare), because I did it and usually in the very last operation I committed. It's easy to trace and fix and makes me stronger, I think, at understanding and securing my system(s).

This applies to such things as reacting with minimal understanding in handling even security updates. If we come to rely on other's judgement for all things secuirty oriented, we can easily knee-jerk to assume we must comply with daily updates. I consider that hugely over-reacting. I never do security updates daily. I have a schedule where once a month I review and handle them all. In almost 20 years and even including a public gaming server on one boxen, and even with the infamous BASH bug, I have never had any intrusion. Part of that might be my exclusion of visiting most social networking sites, but it is nevertheless true. I should mention that I do security updates for clients much more regularly for confidence sake but my own system has been either quite well attended to by once a month scheduling or just very lucky. I think the former.

The most important issue though is relying on the fact that the original manual system is still there to be used, should one desire and that is exactly the point. If one never learns to use it and enjoy the benefits that come with deeper understanding and control, then one very likely never will. Convenience is extremely seductive but it does make us weaker.

I'm not saying anything at all derogatory about you or anyone who chooses this level of convenience at this cost but I do think it is exceedingly important to grasp that cost/benefit relationship and choose very cautiously.

2 members found this post helpful.

I just switched CACHEUPDATE=on, guess I'm late to the party. I just ran slackpkg update, I likes it. Gonna let it ride for awhile, maybe keep it.

Slackpkg+ is an awesome add on to slackpkg. I always used slackpkg for everything concerning Slackware package management. Before slackpkg+, third party package management was with the usual suspects (installpkg, updatepkg, removepkg). I stored packages using a '/home/non-slack/slackbuilds/<package name>/{build,oldpkgs,tmp}/' layout. This included not only packages I built but those from others. For example with Alien Bob's packages I downloaded the build directory via a script for a specific package and run the SlackBuild. If the build fails and I couldn't figure it out, I'd just download the package for install or update. All third party packages or non-slack packages as I like to call then are locally stored, including mirrored Alien Bob's ktown and multilib (on their own tree of '/home/non-slack/' and only the parts I need, plus source).

With the advent of slackpkg+ I was able to easily set up that tree using Alien Bob's gen_repos_files.sh to create a repository for slackpkg+ to use. For a long while I stuck to keeping all third party packages in that tree and used slackpkg to update my system. This has a side benefit of being able to use these local repositories to update my other Slackware installs. Being able to use slackpkg to update third party packages instead of using installpkg, updatepkg, removepkg is a huge plus.

I eventually added the slackpkg+ repository to slackpkg+ and recently decided to add Alien Bob's package repository to slackpkg+ instead of downloading/building to my local repository. That's only a few packages anyway. Of course now I need to add his repository to all my Slackware installs. I may go back to using my local again, better to download once than multiple times.

I still use installpkg, upgradepkg and removepkg as needed. For example, over the course of the last two days I created 79 SlackBuilds (from a template of course) to install a perl module and it's dependencies of dependencies of dependencies using installpkg (used upgradepkg --reinstall a few times and removepkg once) to install the needed dependencies before running a SlackBuild that depended on those dependencies. With these packages now all installed in my repository it simply takes a run of gen_repos_files.sh to setup the new packages, then a simple 'slackpkg update' and 'slackpkg install nonslack' on my other Slackware installations to add the new packages. On this system only a 'slackpkg update' is needed, since they are already installed. In the past I would have ran 'upgradepkg --install-new --reinstall on the repository tree probably doing only for 'perl-' packages instead of the entire tree. Not a lot of difference time wise on doing an upgrade but it really nice to be able to use slackpkg to do this.

1 members found this post helpful.

Interesting, so when there is an update to slackpkg+ the config is overwritten, by the looks of things. Is there any way to avoid that?

You should get asked to update the .config's and then have several options: Keep old, overwrite with new, new but label the old one _old etc... Does that not happen?

1 members found this post helpful.