LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 06-11-2010, 11:01 AM   #76
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Linux Mint 17.1
Posts: 1,424

Rep: Reputation: 138Reputation: 138

gapan

I'm sorry if I caused any offence, however I was pointing out an inability in gslapt/slapt-get to differentiate between a package that was installed and a package in your repository. If gslapt had shown the the Sbo version was installed and the salix one not installed I wouldn't have had a problem. However this was not the case.

I would say however that I was not trying to do anything complex with slapt-get, I only had a single repository identified in the conf file and the program is not particularly difficult to configure and use. Perhaps you would like to try it and you will see it is not a lack of ability but a problem with the programs ability to differentiate between two packages that have the same version number but a different tag.

More importantly I can use the excellent packages that you supply by just downloading and installing manually.

samac
 
Old 06-11-2010, 11:04 AM   #77
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 4,830

Rep: Reputation: Disabled
Quote:
a problem with the programs ability to differentiate between two packages that have the same version number but a different tag
I think what gapan was saying is that slackpkg in this case behaves exactly the same.
 
Old 06-11-2010, 11:11 AM   #78
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Linux Mint 17.1
Posts: 1,424

Rep: Reputation: 138Reputation: 138
Quote:
I think what gapan was saying is that slackpkg in this case behaves exactly the same.
Not quite the same slackpkg will over-write your installed version with the official version, and this is easily stopped by blacklisting, but this is different. It is saying that you have two version of the program installed when in fact only one version is installed.

samac

Last edited by samac; 06-11-2010 at 11:12 AM.
 
Old 06-11-2010, 11:13 AM   #79
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 4,830

Rep: Reputation: Disabled
oops, sorry for misunderstanding: I'm not using slapt-get from years and can't remember it behaved this way.

Last edited by ponce; 06-11-2010 at 11:20 AM.
 
Old 06-11-2010, 02:09 PM   #80
gapan
Member
 
Registered: Feb 2007
Posts: 370

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by samac View Post
I'm sorry if I caused any offence, however I was pointing out an inability in gslapt/slapt-get to differentiate between a package that was installed and a package in your repository. If gslapt had shown the the Sbo version was installed and the salix one not installed I wouldn't have had a problem. However this was not the case.
I'm certain something confused you there, because slapt-get definitely has the ability to differentiate between packages in the way you're describing. If you'd like, you can PM me and I'm sure we will find what went wrong.

Quote:
Originally Posted by samac View Post
Not quite the same slackpkg will over-write your installed version with the official version, and this is easily stopped by blacklisting, but this is different.
slapt-get will do exactly the same. There's absolutely no difference there.

Quote:
Originally Posted by samac View Post
It is saying that you have two version of the program installed when in fact only one version is installed.
I'm not sure how this could happen. But I'm sure we can clear it up with more information.
 
Old 06-11-2010, 04:46 PM   #81
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Linux Mint 17.1
Posts: 1,424

Rep: Reputation: 138Reputation: 138
Unfortunately as it was only an experiment I have deleted all the files, however here is a precis of the steps that I took.

Downloaded slapt-get and installed it. Modified slapt-get.conf to point at a Salix64 repository, did an update. Downloaded Gslapt and ran it. Various packages were reported as being installed but they were not, however the slackbuild version of them was. This included flightgear and its dependencies, lame, audacity and a few others. The programs that were installed could be marked for deletion the others couldn't. On deleting the properly installed programs the "others" vanished, on re-installing they re-appeared.

As gslapt/slapt-get was not reporting the packages on my computer correctly, I decided to "bin" the experiment. Let me say one again however, I would be delighted if I could use a dependency tracking package manager, they should make your life easier but as I have been using Linux exclusively for over 10 years and have used all of the major distributions, and have used pretty much all the package managers that are out there, I have yet to find a dependency tracking package manager that is as good as it thinks it is. It usually ends up, in my experience, with a broken system. I would say that in six years of using Slackware I have only had a catastrophic failure twice. Once when my motherboard died and once when I had a power cut whilst updating glibc.

Quote:
slapt-get will do exactly the same.
I know, but this is irrelevant as it has nothing to do with the problem that I encountered and I would not have a problem with this.

I hope that this clarifies things.

samac
 
Old 06-11-2010, 07:32 PM   #82
veeall
Member
 
Registered: May 2007
Location: Estonia
Distribution: Slackware64-current
Posts: 262

Rep: Reputation: 48
Gslapt indeed shows 'installed' mark next to all packages of the same app if the only difference between installed and repo versions is the builder tag(SBo etc.). Confusing.
 
Old 06-12-2010, 05:02 AM   #83
gapan
Member
 
Registered: Feb 2007
Posts: 370

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by samac View Post
Downloaded slapt-get and installed it. Modified slapt-get.conf to point at a Salix64 repository, did an update. Downloaded Gslapt and ran it. Various packages were reported as being installed but they were not, however the slackbuild version of them was. This included flightgear and its dependencies, lame, audacity and a few others. The programs that were installed could be marked for deletion the others couldn't. On deleting the properly installed programs the "others" vanished, on re-installing they re-appeared.
So you only had a single repository specified in your slapt-getrc and that was the Salix repository? That could be mistake No.1. The salix repositories are not supposed to be used stand-alone in any case. They should always be used in conjuction with a slackware repository, preferably one with dependency support, like this: http://salix.enialis.net/i486/slackware-13.1/
And you should also take care about assigning proper priorities to those repositories, according to your needs.

And I think that what you think you saw, was that slapt-get was indeed detecting your installed packages, but it wanted to replace them with the same packages from the salix repository, which is absolutely what it should do in any case. If you want it to not replace your custom built packages with the ones from the reposotiries, you should either add those packages in the EXCLUDE list in slapt-getrc (like you would do with slackpkg), or you could create a local repository in your hard drive with them and assign a higher priority to that repository (read the slapt-get FAQ to find how to do that).

Quote:
Originally Posted by veeall View Post
Gslapt indeed shows 'installed' mark next to all packages of the same app if the only difference between installed and repo versions is the builder tag(SBo etc.). Confusing.
Huh? No it doesn't. Here's a nice example: http://img808.imageshack.us/img808/7972/gslapt.png

Last edited by gapan; 06-12-2010 at 05:06 PM. Reason: fixed url
 
Old 06-12-2010, 08:01 AM   #84
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Linux Mint 17.1
Posts: 1,424

Rep: Reputation: 138Reputation: 138
Quote:
I think that what you think you saw
I think you think what you want to think to make people think that they are thinking incorrectly.

Are two people imagining the same problem? As for being used with a Slackware repository, how would that cause an invalid interaction with SBo packages.

It may work perfectly on your system but that does not mean that it works perfectly on all systems. Accept the fact that it may have a problem. I have and that doesn't bother me, it just means that I will stick with slackpkg and pkgtools for the time being.

samac
 
Old 06-12-2010, 08:49 AM   #85
gapan
Member
 
Registered: Feb 2007
Posts: 370

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by samac View Post
I think you think what you want to think to make people think that they are thinking incorrectly.

Are two people imagining the same problem?
Right. It's completely impossible you're making the same mistake.

Quote:
Originally Posted by samac View Post
As for being used with a Slackware repository, how would that cause an invalid interaction with SBo packages.
If you don't have a complete slackware installation, you might be missing a package from the slackware repositories, which is required by the package you want to install. If a slackware repository is not specified in slapt-getrc, then the dependency is nowhere to be found, so the package you want to install is impossible to install.

Quote:
Originally Posted by samac View Post
It may work perfectly on your system but that does not mean that it works perfectly on all systems.
Yes it does. If you know how to use slapt-get properly, you won't get anything like that.

Quote:
Originally Posted by samac View Post
Accept the fact that it may have a problem.
No I won't, unless you provide some concrete evidence. What you have provided until now is a vague description of what you remember you did. You will need to provide specific steps to reproduce your problem. How about I open a thread titled "slackpkg sucks" and all I say is "it doesn't work right, it messed my system, I don't really remember what I did and I removed my slackware installation so you'll just have to accept the fact that it sucks".

Quote:
Originally Posted by samac View Post
I have and that doesn't bother me, it just means that I will stick with slackpkg and pkgtools for the time being.
You're free to do anything you want, but my initial reply to you still stands: "You shouldn't blame a tool, when you should only be blaming your inability to use it."
 
Old 06-12-2010, 10:09 AM   #86
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Linux Mint 17.1
Posts: 1,424

Rep: Reputation: 138Reputation: 138
gapan

I really don't understand why you are being so defensive. Maybe some of what I have said is lost in translation. Let us call this part of the thread closed as we are obviously not going to agree and I do not have the inclination to continue the discussion with you.

samac
 
Old 06-12-2010, 10:30 AM   #87
gapan
Member
 
Registered: Feb 2007
Posts: 370

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by samac View Post
gapan

I really don't understand why you are being so defensive. Maybe some of what I have said is lost in translation. Let us call this part of the thread closed as we are obviously not going to agree and I do not have the inclination to continue the discussion with you.

samac
I'm simply pointing out that the problem you had is not a problem with slapt-get or dependencies, but probably something you did wrong. The impression that your first post leaves concerning this part is that dependencies don't work right with slapt-get, which is false. I offered to help you determine what the problem was and I didn't want to do it in this thread in the first place, I suggested you sent me a PM and we could continue our discussion there. I don't have anything against you and my posts are not hostile, I think, at least not intentionally, and if you're received them that way, I apologize, that wasn't my intention. We can leave this here, no problem with me. My offer to help with understanding you problem still stands though.
 
Old 06-12-2010, 12:33 PM   #88
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,897

Rep: Reputation: 578Reputation: 578Reputation: 578Reputation: 578Reputation: 578Reputation: 578
Any dependency-resolving package manager can only be as good as the dependency data it has access to. This is true whether the system uses a centralized database(single file) or the data is included in the packages themselves.
In the case of slapt-get it can use both. The repo must have a MANIFEST which includes the dependency data. If you use Slackware packages from an official repo, or build and install your own packages the packages contain no such data so using them with slapt-get is always gonna be susceptible to problems. Using available tools you can generate a usable MANIFEST for
any group of packages you like. This works best when each package includes already includes a slack-required file.

Packaging systems are usually designed with a particular package format. And the content of the packages can be managed/distributed in order to work with whatever dependency-resolution scheme is being used. There are some slackware packages which don't lend themselves well to dependency resolution. For instance the aaa_elflibs package which contains single or several files from a wide range of packages. So, resolving the dependencies for things like lib_gcc.so is very weird for any straight-forward scheme of pin-pointing which package contains a certain file. Say you want to create a binary-only (runtime) installation, but decide to not install aaa_elflibs and install the full packages which contain the files from aaa_elflibs -you'll wind up having gcc installed because lib_gcc is only available in either aaa_elflibs or with the gcc package. And any scheme which uses a 'suggests' feature will want to install lots of other packages to go with gcc... The point is that creating any dep-res software which even half-way works, means fine-tuning the distribution of the content among the packages in such a way that things work as wished. The algorithms used must be matched with the package content.
 
1 members found this post helpful.
Old 06-12-2010, 03:16 PM   #89
veeall
Member
 
Registered: May 2007
Location: Estonia
Distribution: Slackware64-current
Posts: 262

Rep: Reputation: 48
Quote:
Originally Posted by gapan View Post
Huh? No it doesn't. Here's a nice example: http://img808.imageshack.us/img808/7972/gslapt.png
Sorry, but it seems that it does
http://www.upload.ee/image/632145/pilt20100176.png

Edit: My Gslapt version is 0.5.3b, package is from software.jaos.org.
Here are two with different 'arch' and with and without 'builder' tag, both marked as 'installed': http://www.upload.ee/image/632182/pilt20100176_.png

Last edited by veeall; 06-12-2010 at 03:50 PM.
 
1 members found this post helpful.
Old 06-12-2010, 05:16 PM   #90
gapan
Member
 
Registered: Feb 2007
Posts: 370

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by gnashley View Post
Any dependency-resolving package manager can only be as good as the dependency data it has access to. This is true whether the system uses a centralized database(single file) or the data is included in the packages themselves.
In the case of slapt-get it can use both. The repo must have a MANIFEST which includes the dependency data. If you use Slackware packages from an official repo, or build and install your own packages the packages contain no such data so using them with slapt-get is always gonna be susceptible to problems. Using available tools you can generate a usable MANIFEST for
any group of packages you like. This works best when each package includes already includes a slack-required file.
Agreed, for the most part. It's not the MANIFEST file, but the PACKAGES.TXT file. Also, if the repository has no dependency data, the only problem that it would cause, is that slapt-get will not support dependencies for that repository, which is not odd at all.

Quote:
Originally Posted by gnashley View Post
Packaging systems are usually designed with a particular package format. And the content of the packages can be managed/distributed in order to work with whatever dependency-resolution scheme is being used. There are some slackware packages which don't lend themselves well to dependency resolution. For instance the aaa_elflibs package which contains single or several files from a wide range of packages. So, resolving the dependencies for things like lib_gcc.so is very weird for any straight-forward scheme of pin-pointing which package contains a certain file. Say you want to create a binary-only (runtime) installation, but decide to not install aaa_elflibs and install the full packages which contain the files from aaa_elflibs -you'll wind up having gcc installed because lib_gcc is only available in either aaa_elflibs or with the gcc package. And any scheme which uses a 'suggests' feature will want to install lots of other packages to go with gcc... The point is that creating any dep-res software which even half-way works, means fine-tuning the distribution of the content among the packages in such a way that things work as wished. The algorithms used must be matched with the package content.
You're forgetting that you can assign alternative dependencies. For example: "cxxlibs|gcc-g++|aaa_elflibs" means any of the 3 is accepted. So, that's not a problem at all.

Quote:
Originally Posted by veeall View Post
Sorry, but it seems that it does
http://www.upload.ee/image/632145/pilt20100176.png

Edit: My Gslapt version is 0.5.3b, package is from software.jaos.org.
Here are two with different 'arch' and with and without 'builder' tag, both marked as 'installed': http://www.upload.ee/image/632182/pilt20100176_.png
Aha! I think I know where you went wrong. As I stated in a previous post, the salix repository should always be used in conjuction with a slackware repository and you also need to take care of assigning repository priorities properly. Try using these for your slapt-getrc and I'm betting your problem will go away (don't forget to update the package database in gslapt):
Code:
SOURCE=http://salix.enialis.net/x86_64/slackware-13.1/:OFFICIAL
SOURCE=http://salix.enialis.net/x86_64/13.1/:PREFERRED
this will give priority to the salix repository over the slackware one for packages that appear in both, you can assign priorities in the opposite way if you want the slackware repository to have a higher priority.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Package updater unable to resolve dependencies FC8 jayunplugged Fedora 2 03-07-2008 09:56 PM
Article about Slackware's 'Magic Package Maker( src2pkg) gnashley Slackware 22 12-01-2007 09:11 PM
LXer: A look at Slackware's package utilities LXer Syndicated Linux News 0 02-20-2007 11:46 PM
Poll: Yast Package Manager vs. Smart Package Manager in 10.1 agentchange SUSE / openSUSE 6 06-02-2006 08:29 AM
unsatisfied dependencies for smart package manager on PClinuxOS m.r.bob Linux - Distributions 5 01-16-2006 03:41 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:53 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration