Salix Forums

Hello,

If I make a local package and install it either by spkg or installpkg or use a pkg from SlackBuilds (even by slapt-src),

AND

the package is already available in a slapt-get repo, whenever I use slapt-get --upgrade, the package is about to be replaced (i.e. downgraded) by the version from the slapt-get repo. But this is exactly NOT what one needs, if one had to make the local version of the package.

To mend this inconvenience I was already suggested to make a local repo (http://www.salixos.org/forum/viewtopic. ... 125#p17125) and add it to slapt-get sources. Well, all right, but it requires to create PACKAGES.TXT and CHECKSUMS.md5 every time I add a package manually. And if build by slapt-src, I have to move the package first to the local repo dir and update the two files before being installed. All this is a redundant bother!

How about setting SOMEHOW that packages installed NOT by slapt-get are already flagged with the highest priority so that no accidental downgrade or replacement happens?

Please, what do the people here think about it?

That sounds good to me though I have no knowledge of how it may be done?
perhaps just adding the packages to EXCLUDES for now?

crocusino wrote:How about setting SOMEHOW that packages installed NOT by slapt-get are already flagged with the highest priority so that no accidental downgrade or replacement happens?

There's no way to tell that. Packages that are installed by slapt-get are installed using spkg anyway. What you have been suggested before, is the way to go.

I thank you very much for your responses, but it seems I am perhaps the only one who uses slapt-src. No one else has similar problems?

Well, for now the extra local repo is the only practical way (or also the exclude list) how to deal with local and slapt-src packages. In my view it delegates too much unnecessary stuff to the admin, which could (and should) be done automatically.

But apart from that, is this the right way? Then why have we a cool slapt-src tool to conveniently install many additional software packages, which may however be stupidly destroyed (i.e. replaced, downgraded) by accident by its good fellow slapt-get every time one makes a system update (e.g. for security reasons)?

If slapt-get depends on spkg, then it (i.e. slapt-get and gslapt) could just keep a note what packages slapt-get installed and possibly upgrade only those. If an upgrade of a manually installed package is available, slapt-get could just only mention that possibility.

What do you think?

Just excluding the packages is straightforward, though perhaps a bit messy. I have two or three like that, and I must check to see if it's still needed - the repos may by now have the same versions.

There is just no way to implement this with Slackware package management. It doesn't store enough informations regarding package states properly. To support such a feature the package management would need to be rebuilt from scratch and I doubt the Slackware base is ever going to do this and Salix doesn't want to derive from Slackware.
You're best bet is probably to automatically add packages installed by slapt-src to the excludes. I think slapt-src provides some kind of hook feature which could be used for this.

crocusino wrote:Then why have we a cool slapt-src tool to conveniently install many additional software packages, which may however be stupidly destroyed (i.e. replaced, downgraded) by accident by its good fellow slapt-get every time one makes a system update (e.g. for security reasons)?

Why are you installing something with slapt-src, if it's already available as a binary package with slapt-get?

crocusino wrote:Well, for now the extra local repo is the only practical way (or also the exclude list) how to deal with local and slapt-src packages. In my view it delegates too much unnecessary stuff to the admin, which could (and should) be done automatically.

Self compiling stuff that is already available in the official repository already is unnecessary for the usual user/admin

I understand as a package could be available with more options or with a newer version in slapt-src repositories. It's kinda rare. So for me, I just add the package to exclude list and check some times if the version is now ok in Salix repo or not.
Yes this is not automatic, but it's working pretty good.
The kind of way you want it to be automatic needs a lot more information from packaging installed and at the end, the only package management that is close to do it correctly is apt-get. And the problem with apt-get is that it is very complicate and so it's really distant from the KISS principle of Slackware and Salix.
So, sorry, no easy way. But perhaps usin a hook in slapt-src as suggested could be a good idea (I'm interrested if possible).

Hm, thank you again for your views.

Yes, it is mainly the customization of a package that makes rebuilding packages necessary. But in my situation, it is just the fact that the official lapack package has a bug (missing soft links to liblapack.so ...) and other sw depending on it fails to build... It's why I have the lapack from slapt-src. I wrote about this problem earlier in the BUG section of the forum http://www.salixos.org/forum/viewtopic.php?f=15&t=2677, but the broken package is still there without a mark of official remedy.

As for the ability of Slackware package management to deal with such situations - I absolutely don't see a relevance. This could simply be a job for the slapt-get program. Just to keep a note (in some logfile or so) which packages it installed and possibly upgrade only those and no else. But I can imagine that by simply setting the package in the EXCLUDE list may do the job well.

I could not find that smart hook in slapt-src. If someone knows, please share your knowledge

Happy New Year!