A proposal regarding the _registration_ of package dependencies by Pkgtools
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.
A proposal regarding the _registration_ of package dependencies by Pkgtools
A topic that was discussed here quite bright, was recording dependencies by Pkgtools without these dependencies to be managed automatically, of course.
Here comes my proposal, which is a very small change of installpkg.
As you can see, installpkg records in the packages database these dependencies, if they are present in the slapt-get style, but does not imply any automatic management.
You'll wonder, why is it useful to record dependencies if they are completely ignored?
Well, the best example is even consulting them directly by user, but even allows you to write/modify an 3rd-party application to manage them efficiently, why not?
Here is the patch:
Code:
--- installpkg.orig 2011-07-12 19:24:58.799760205 +0300
+++ installpkg 2011-07-12 19:26:12.776304855 +0300
@@ -533,7 +533,9 @@
done
rm -f $TMP/tmplist$$
- # Write the package file database entry and install the package:
+ # Install the package and write the package file database entry:
+ ( cd $ROOT/ ; $packagecompression -dc | $TAR -xlUpvf - ) < $package >> $TMP/$shortname 2> /dev/null
+
echo "PACKAGE NAME: $shortname" > $ADM_DIR/packages/$shortname
echo "COMPRESSED PACKAGE SIZE: $COMPRESSED" >> $ADM_DIR/packages/$shortname
echo "UNCOMPRESSED PACKAGE SIZE: $UNCOMPRESSED" >> $ADM_DIR/packages/$shortname
@@ -542,13 +544,24 @@
if [ $MD5SUM = 1 ]; then
echo "PACKAGE MD5SUM: $(md5sum $package | cut -f 1 -d ' ')" >> $ADM_DIR/packages/$shortname
fi
+ # Record the required dependencies if exists:
+ if [ -f $ROOT/install/slack-required ]; then
+ echo "PACKAGE REQUIRED: $(cat $ROOT/install/slack-required | xargs -r -iZ echo -n 'Z, ' | sed -e 's/, $//')" >> $ADM_DIR/packages/$shortname
+ fi
+ # Record the package conflicts if exists:
+ if [ -f $ROOT/install/slack-conflicts ]; then
+ echo "PACKAGE CONFLICTS: $(cat $ROOT/install/slack-conflicts | xargs -r -iZ echo -n 'Z, ' | sed -e 's/, $//')" >> $ADM_DIR/packages/$shortname
+ fi
+ # Record the suggested packages if exists:
+ if [ -f $ROOT/install/slack-suggests ]; then
+ echo "PACKAGE SUGGESTS: $(cat $ROOT/install/slack-suggests | xargs -r)" >> $ADM_DIR/packages/$shortname
+ fi
echo "PACKAGE DESCRIPTION:" >> $ADM_DIR/packages/$shortname
cat $DESCRIPTION | grep "^$packagebase:" >> $ADM_DIR/packages/$shortname 2> /dev/null
if [ "$shortname" != "$packagebase" ]; then
cat $DESCRIPTION | grep "^$shortname:" >> $ADM_DIR/packages/$shortname 2> /dev/null
fi
echo "FILE LIST:" >> $ADM_DIR/packages/$shortname
- ( cd $ROOT/ ; $packagecompression -dc | $TAR -xlUpvf - ) < $package >> $TMP/$shortname 2> /dev/null
if [ "$(cat $TMP/$shortname | grep '^\./' | wc -l | tr -d ' ')" = "1" ]; then
# Good. We have a package that meets the Slackware spec.
cat $TMP/$shortname >> $ADM_DIR/packages/$shortname
Last edited by Darth Vader; 07-12-2011 at 11:59 AM.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Interesting. What is a dependency? Are we talking only about recording linked libraries, build time dependencies, stuff required for the app to function (eg. k3b requires cdrtools but doesnt link against it), all/some of the above?
Interesting. What is a dependency? Are we talking only about recording linked libraries, build time dependencies, stuff required for the app to function (eg. k3b requires cdrtools but doesnt link against it), all/some of the above?
We talk just about dependencies as defined by the well-known slapt-get tool. And slapt-get known only about package names. So, it's about required packages, suggested packages and conflicts between packages.
Last edited by Darth Vader; 07-12-2011 at 12:17 PM.
Slackbuils can be, and are, modified by the users to change dependencies.
Such messages could be confused with the compile and linking messages.
IMO I don't think we have a problem with dependencies.
How you'll be confused by some lines written on i.e. /var/log/packages/k3b-2.0.2-i486-2 file with compiling and linking messages?
Anyway, the SlackBuild.org builds, usually, do not offer slapt-get-like dependencies information (yet), so nothing new will be present in packages database ...
Last edited by Darth Vader; 07-12-2011 at 03:59 PM.
Congratulations! It's incredible! It's fantastic! Pkgtools really register dependencies! But I found a big flaw in your plan to conquer the world: it seems that no application is able to interpret this new information, even that glorious slapt-get.
So what next? We must stare every time at these 'recorded' dependencies?
So what next? We must stare every time at these 'recorded' dependencies?
To be honest, that's right my idea ...
However, these lines are recorded in a jam style that can easily be interpreted by a machine.
I believe that if this style of dependencies recording is adopted, it will be very easy to modify that ... slapt-get to use this information, for example ...
Congratulations! It's incredible! It's fantastic! Pkgtools really register dependencies! But I found a big flaw in your plan to conquer the world: it seems that no application is able to interpret this new information, even that glorious slapt-get.
So what next? We must stare every time at these 'recorded' dependencies?
Change "PACKAGE REQUIRED:" to "PACKAGE REQUIRES:" and I think that slapt-get will understand it.
No, that should be "REQUIRED". "REQUIRES" is an error in the slapt-get FAQ.
slapt-get just never parses that information from files in /var/log/packages, it only parses the dependency information from the PACKAGES.TXT file in repositories (if there is such information). I don't see any use for this patch. When you run:
Code:
slapt-get --show packagename
you will get the dependency information from the repository anyway.
Another wrong assumption this patch makes is that dependency information is always stored inside the package in the form of slack-required/conflicts/suggests files. But that is not true at all. All slapt-get looks for is the dependency information in the PACKAGES.TXT in the repositories. How you put the dependency information in the PACKAGES.TXT file is another matter and slapt-get doesn't have to do anything with that. In fact, having the dependency information inside the package like this is completely inefficient imho. What do you do if you want to edit the dependencies for some reason? Rebuild the package? The horror...
Exploding a package, altering the dependency list file and then repackaging it doesn't sound all that horrific to me, especially with the very simple nature of slackware's package format and tools.
Though it's probably the most common usage, dependency tracking isn't solely about pulling stuff from repos: it should also cater for offline installation of packages that may have already been downloaded manually, and internalising the dependency list is probably the only reliable way of doing that
Having said that. I'm firmly in the "Dependency tracking causes just as many problems as it solves and there's no good way to do it, so don't even try" camp.
Exploding a package, altering the dependency list file and then repackaging it doesn't sound all that horrific to me, especially with the very simple nature of slackware's package format and tools.
Doesn't it? Try doing it for a couple of hundred packages then. Or even a few dozen. And compare:
Method 1:
1. Explode package
2. Edit dependency information manually
3. Repackage
4. Goto step 1 for every next package you have
5. Upload new packages
6. Force every user to upgrade packages that haven't been altered in any way, other than updating a piece of text (and waste their bandwidth as well as the server's bandwidth)
Method 2:
1. Correct the dependency information that lies outside the package
Even for a single package, that is a big difference.
Quote:
Originally Posted by GazL
Though it's probably the most common usage, dependency tracking isn't solely about pulling stuff from repos: it should also cater for offline installation of packages that may have already been downloaded manually, and internalising the dependency list is probably the only reliable way of doing that
The repositories don't have to be online. You can create local, offline repositories any time. With or without dependency information. In any case, if you download a package manually, you can also download the separate dependency information manually.
Quote:
Originally Posted by GazL
Having said that. I'm firmly in the "Dependency tracking causes just as many problems as it solves and there's no good way to do it, so don't even try" camp.
If all you've seen is the wrong way to do it, then of course you believe there is no good way to do it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
