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.
Well, not sure about that. If by "same repo" you mean "checked by the same person who commits all changes", you are probably right as this person hopefully bears in mind the conflicts (that can be harmless or not).
Well known examples in Slackware are the packages that install libraries already shipped in aaa_elflibs (but Patrick takes care of making sure this doesn't hurt), and until the packaging changed, glibc that shippped files already shipped in other glibx-* packages for instance. The same is probably true for Salix and the checks made by George.
By the way these examples are not so similar: the files shipped in the new vs already installed packages are (or at least were) not the same in the case of aaa_elflibs but were the same in case of glibc-*. Whether they are identical or not can checked by the tools comparing the checksums, for instance.
But what if the repo ships thousands of packages built from SlackBuilds provided many people who are not aware of the other packages? Maybe slackrepo can do or help to do these checks then, I don't know. David, could you shed some light here?
I think he just meant it would inform users of packages that are listed as dependencies that are already installed. So, for example, if you already have python3 installed and try to install python3-PyQt5, which eventually has python3 as a dependency (through python3-sip, which is a dependency of python3-PyQt5), it wouldn't prompt you to recompile/reinstall python3.
But what if the repo ships thousands of packages built from SlackBuilds provided many people who are not aware of the other packages? Maybe slackrepo can do or help to do these checks then, I don't know. David, could you shed some light here?
It's a lot of work, so nobody does that, but it might be interesting to script something and run it once before SBo-14.2 is released, so we can make sure the README files are accurate. And also, that will help me to finish the support for "CONFLICTS", which (as you saw earlier, Didier) is almost completely missing and I had forgotten about. So thanks for the interesting and useful question
(Hardcoding the wxEverything conflicts would fix 99.8% of the problem )
To go back to your question Hosein, yes, you are right, as you say it is harmless as long as packages are gathered from same repository. The repository owner needs to worry about optional dependencies, and upgrades, and rebuilds, and conflicts, but not you.
But there are lots of people who don't know that, and arrive here on LQ with problems, so it's an interesting and very useful idea from Dimitris to put that warning in slpkg.
Well, I'm the voice of newbies here.
At the moment I don't have slpkg on my system. As far as I remember, during dealing with binary repositories slpkg displays already installed dependencies with green color and automatically doesn't re-download and reinstall them again (Dimitris added this feature with my suggestion, thanks). I think this conservative approach help newbies to not destroy their system. But, even without this feature, users shouldn't have any problem if they don't install packages from various repositories as already installed third party dependencies replaced with packages from same repository. Hence, as a newbie, I have 2 recommendation for other newbies:
1- Don't try to install packages from various repositories
2- Be careful about packages which tend to overwrite official packages with their upgraded/downgraded/rebuilt dependencies. Don't install them without consultation with slackers.
Here's a list of the 315 tuples of conflicting packages in Slackware-current (32 bit, not including extra/) and all the packages (32 bit) built by SBo, with a count of the number of files that collide:
And here's the complete list of all the file collisions in Slackware and SBo -- it's nearly 2 Mb and forty thousand lines long, so don't download it unless you are basically crazy:
dealing with binary repositories slpkg displays already installed dependencies with green color and automatically doesn't re-download and reinstall them again
I had issues with slpkg. But I had compiled packages from source, prepackaged ones from Eric's repo and from SBo. slpkg was trying to "upgrade" packages to previous releases that I had compiled myself. (Supposedly he added a option to not "upgrade" packages with a newer release already installed, but I could never get it to work.) This probably wouldn't be an issue for newbs using 14.1 and pulling from the SBo 14.1 repo, but slpkg can be configured to pull from many repos which could potentially lead to problems.
Honestly, I think that the safest and best thing to do is to not use any automated "package managers", slackpkg aside. Not only does this ensure that you are not "reinstalling" some packages, but you also learn from the experience.
Here's a list of the 315 tuples of conflicting packages in Slackware-current (32 bit, not including extra/) and all the packages (32 bit) built by SBo, with a count of the number of files that collide:
And here's the complete list of all the file collisions in Slackware and SBo -- it's nearly 2 Mb and forty thousand lines long, so don't download it unless you are basically crazy:
I had issues with slpkg. But I had compiled packages from source, prepackaged ones from Eric's repo and from SBo. slpkg was trying to "upgrade" packages to previous releases that I had compiled myself. (Supposedly he added a option to not "upgrade" packages with a newer release already installed, but I could never get it to work.) This probably wouldn't be an issue for newbs using 14.1 and pulling from the SBo 14.1 repo, but slpkg can be configured to pull from many repos which could potentially lead to problems.
Honestly, I think that the safest and best thing to do is to not use any automated "package managers", slackpkg aside. Not only does this ensure that you are not "reinstalling" some packages, but you also learn from the experience.
As far as I know, there is an option for slpkg to not "downgrade" packages (I think Dimitris added it by your request) but I did't test it. Overall, you are right, if users use slpkg for different repos it is possible to break their system as slpkg is completely tag-blind.
And regrading automated package managers, you are absolutely correct. For that reason, I don't use any of them to garb and install packages on my system. I'm just using sbotools to update my local copy of SBo. If a package exist in Alien repository I will use it. If not, I use hoorex to track its dependencies through local SBo and then I will download, build and install them manually.
As far as I know, there is an option for slpkg to not "downgrade" packages (I think Dimitris added it by your request) but I did't test it.
Yea, that is what I meant by slpkg was trying to "upgrade" packages. A little word play there. I tried it but if I remember correctly it still listed the packages that I compiled myself and wanted to remove them and install the version that was recommended by the SBo .info files. So I didn't let it proceed and was blacklisting them as I went, but I figured that it was taking just as much time to do that as it would have been for me to just run the SlackBuild myself.
@David: I had a look at the collisions list and the tuples built from them. Very interesting.
These lists could be made available to the SlackBuilds maintainers, who could use them to:
check which of their packages are among the tuples,
grep collisions to see which files are overwritten,
assess the collisions: some are harmless (e.g. replacing a file by itself), others not,
in case of harmful collisions, insert a warning in the README
possibly consult with the maintainers of the conflicting SlackBuilds, about how to avoid collisions if possible, else inform the users consistently.
A line beginning with "CONFLICTS=" in the .info would help as it could be parsed by the package tools (and help feeding the corresponding line in PACKAGES.TXT)
Just my two ¢.
PS in collisions I see that some packages belong to more than one category. Is it normal? Just wondering if it's really the same package then. Examples:
PS in collisions I see that some packages belong to more than one category. Is it normal? Just wondering if it's really the same package then. Examples:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
