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.
The dependency resolution provided by slpkg is based on what the package maintainer specifies. If you get all your packages from one source, you'll likely never run into issues with library versions mismatching.
If Package Maintainer A provides you with Package-1.1 that requires Library-1.2, and Package Maintainer B provides you with Package-1.1 that requires Library-1.3, how is slpkg going to know what to do if you go to install the package from Maintainer A, but you have the library from Maintainer B installed as a dependency of a different program? This is why it is not recommended to mix package repos. While you may not run into collisions frequently, when you do, they can be quite troublesome... plus take into account being the person developing slpkg and trying to determine whether Library v1.2 or v1.3 should be installed. The libraries aren't always backwards compatible.
Like I said, if you get all packages from one source, then you likely won't run into collisions, but if you're grabbing them from many different repos, the chance of issues goes up. Why put the extra burden on the maintainer for supporting something that can very easily cause breakage?
The dependency resolution provided by slpkg is based on what the package maintainer specifies. If you get all your packages from one source, you'll likely never run into issues with library versions mismatching.
If Package Maintainer A provides you with Package-1.1 that requires Library-1.2, and Package Maintainer B provides you with Package-1.1 that requires Library-1.3, how is slpkg going to know what to do if you go to install the package from Maintainer A, but you have the library from Maintainer B installed as a dependency of a different program? This is why it is not recommended to mix package repos. While you may not run into collisions frequently, when you do, they can be quite troublesome... plus take into account being the person developing slpkg and trying to determine whether Library v1.2 or v1.3 should be installed. The libraries aren't always backwards compatible.
Like I said, if you get all packages from one source, then you likely won't run into collisions, but if you're grabbing them from many different repos, the chance of issues goes up. Why put the extra burden on the maintainer for supporting something that can very easily cause breakage?
+1
Maintainer knows best what version dependencies must be installed on the system to work well, so slpkg conformant to the package instructions.
The dependency resolution provided by slpkg is based on what the package maintainer specifies. If you get all your packages from one source, you'll likely never run into issues with library versions mismatching.
If Package Maintainer A provides you with Package-1.1 that requires Library-1.2, and Package Maintainer B provides you with Package-1.1 that requires Library-1.3, how is slpkg going to know what to do if you go to install the package from Maintainer A, but you have the library from Maintainer B installed as a dependency of a different program? This is why it is not recommended to mix package repos. While you may not run into collisions frequently, when you do, they can be quite troublesome... plus take into account being the person developing slpkg and trying to determine whether Library v1.2 or v1.3 should be installed. The libraries aren't always backwards compatible.
Like I said, if you get all packages from one source, then you likely won't run into collisions, but if you're grabbing them from many different repos, the chance of issues goes up. Why put the extra burden on the maintainer for supporting something that can very easily cause breakage?
I don't get packages from many places; *Slackware-current*, a few from Eric's repo, and a few from SlackBuilds. That's it.
Quote:
Originally Posted by dslackw
+1
Maintainer knows best what version dependencies must be installed on the system to work well, so slpkg conformant to the package instructions.
Weak argument. Most likely the maintainer doesn't update their SlackBuild everytime a dependent package gets upgraded/rebuilt/whatever that comes in the default installation of Slackware. While slpkg is conforming to the package instructions, it is reliant on what the maintainer has specified as a dependency that is not already in the default installation of Slackware and will likely be on SlackBuilds. Slackbuilds can and do depend on other packages that are in the default installation of Slackware that are not listed as dependencies in the SlackBuild itself.
So what is the difference if packages in the default install of Slackware get updated to a package that has been compiled and installed by the user to a possibly outdated version on Slackbuilds?
*This could all just be because of the pending release, hopefully it sorts itself out.
@Skaendo: if you know a way to enhance slpkg so that it does what you think it should do, I suggest that you propose a patch. If that works and cause neither issue nor regression, I am sure that Dimitris will gladly apply it.
Weak argument. Most likely the maintainer doesn't update their SlackBuild everytime a dependent package gets upgraded/rebuilt/whatever that comes in the default installation of Slackware.
It should...
One example for package pyvim from SBo.
pyvim need some dependencies to work ok?
etc
ptpython == 0.28
prompt_toolkit == 0.57
If you have already install ptpython 0.29 and slpkg skip downgrade this package build perhaps failed.
From pyvim setup.py file (please see install_requires):
Code:
setup(
name='pyvim',
author='Jonathan Slenders',
version=pyvim.__version__,
license='LICENSE',
url='https://github.com/jonathanslenders/pyvim',
description='Pure Pyton Vi Implementation',
long_description=long_description,
packages=find_packages('.'),
install_requires = [
'prompt-toolkit==0.57',
'ptpython==0.28', # For the Python completion (with Jedi.)
'pyflakes', # For Python error reporting.
'docopt', # For command line arguments.
],
entry_points={
'console_scripts': [
'pyvim = pyvim.entry_points.run_pyvim:run',
]
},
)
Weak argument. Most likely the maintainer doesn't update their SlackBuild everytime a dependent package gets upgraded/rebuilt/whatever that comes in the default installation of Slackware. While slpkg is conforming to the package instructions, it is reliant on what the maintainer has specified as a dependency that is not already in the default installation of Slackware and will likely be on SlackBuilds. Slackbuilds can and do depend on other packages that are in the default installation of Slackware that are not listed as dependencies in the SlackBuild itself.
So what is the difference if packages in the default install of Slackware get updated to a package that has been compiled and installed by the user to a possibly outdated version on Slackbuilds?
*This could all just be because of the pending release, hopefully it sorts itself out.
I think you're trying too hard to get dependency management fully integrated into a distro that doesn't support it. This program will look at the dependencies provided by the package manager and will attempt to install them from the same repo. That's it! If you're attempting to use package repos that are designed for 14.1 on -current, then that is on you. Unless they specify otherwise, those repos expect a full installation of 14.1 on your system, and if you don't have that, then it is up to you to determine how to proceed. If 14.1 didn't include a dependency that the program requires by -current has added it, you need to figure out if that will work for the program you install. Why should slpkg downgrade a system package because package A was built with an earlier version? Or what will happen if package A requires the version it was built against, but -current runs a newer version? Very few repos (I only know of Eric's) provide pre-compiled package support for -current. If you're willing to venture into those waters, be prepared to run into issues.
As is always the case, when you run -current, you're expected to be able to resolve issues yourself. If you can't manage that, maybe you should look at running the latest stable release, because that is much more well supported.
I think you're trying too hard to get dependency management fully integrated into a distro that doesn't support it.
I just thought that it would be nice if slpkg didn't try to downgrade already installed packages (that are not hard coded into the setup.py like for pyvim that dslackw exampled). If it is hard coded into the setup then you should get an error when trying to compile, correct?
I can do dependency management manually, and have since I began using Slackware. I just liked slpkg and would have liked it to not try and downgrade packages that I have compiled and installed. While blacklisting does work it is counter-productive if one of the packages that are blacklisted gets updated.
Is there or could there be a way to tell slpkg to not reinstall a package? Example; slpkg -s sbo vlc -ffmpeg
I installed virtualbox using slpkg from slackonly repository. However, virtualbox is not running:
Code:
root[~]# slpkg -f virtualbox
Packages with matching name [ virtualbox ]
[ installed ] - virtualbox-4.3.24-i486-2_slack
[ installed ] - virtualbox-kernel-4.3.24_3.10.17_smp-i486-1_slack
Found summary
===============================================================================
Total found 2 matching packages.
Size of installed packages 141.42 Mb.
root[~]# exit
exit
xyz[etc]$ virtualbox
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
available for the current kernel (3.10.17-smp) or it failed to
load. Please recompile the kernel module and install it by
sudo /etc/init.d/vboxdrv setup
You will not be able to start VMs until this problem is fixed.
xyz[etc]$ sudo ./rc.d/rc.vboxdrv setup
Not implemented! Please use the virtualbox-kernel.SlackBuild available at SlackBuilds.org instead.
I just thought that it would be nice if slpkg didn't try to downgrade already installed packages (that are not hard coded into the setup.py like for pyvim that dslackw exampled). If it is hard coded into the setup then you should get an error when trying to compile, correct?
I can do dependency management manually, and have since I began using Slackware. I just liked slpkg and would have liked it to not try and downgrade packages that I have compiled and installed. While blacklisting does work it is counter-productive if one of the packages that are blacklisted gets updated.
Is there or could there be a way to tell slpkg to not reinstall a package? Example; slpkg -s sbo vlc -ffmpeg
I installed virtualbox using slpkg from slackonly repository. However, virtualbox is not running:
Code:
root[~]# slpkg -f virtualbox
Packages with matching name [ virtualbox ]
[ installed ] - virtualbox-4.3.24-i486-2_slack
[ installed ] - virtualbox-kernel-4.3.24_3.10.17_smp-i486-1_slack
Found summary
===============================================================================
Total found 2 matching packages.
Size of installed packages 141.42 Mb.
root[~]# exit
exit
xyz[etc]$ virtualbox
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
available for the current kernel (3.10.17-smp) or it failed to
load. Please recompile the kernel module and install it by
sudo /etc/init.d/vboxdrv setup
You will not be able to start VMs until this problem is fixed.
xyz[etc]$ sudo ./rc.d/rc.vboxdrv setup
Not implemented! Please use the virtualbox-kernel.SlackBuild available at SlackBuilds.org instead.
Yes, (sudo)"groupadd -g 215 vboxusers" (and adding user to this group) as mentioned in (VirtualBox Slackbuilds) README file (and relogging) did the trick. Thanks.
slpkg 3.1.1 released and added feature don't downgrade packages, setting via configuration file "/etc/slpkg/slpkg.conf".
Set variable NOT_DOWNGRADE=on.
slpkg 3.1.1 released and added feature don't downgrade packages, setting via configuration file "/etc/slpkg/slpkg.conf".
Set variable NOT_DOWNGRADE=on.
Thank you!
I must say that of all the package managers that I have tried I like your the most. I'm not just saying that, I think that you have done an excellent job with how it builds from SlackBuilds.org, and how easy it is to set up and configure.
I must say that of all the package managers that I have tried I like your the most. I'm not just saying that, I think that you have done an excellent job with how it builds from SlackBuilds.org, and how easy it is to set up and configure.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
