A way of extending the PKGTOOLS for handling Groups
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 way of extending the PKGTOOLS for handling Groups
Idea is very simple:
To extend the PKGTOOLS to handle "install/slack-groups" files, where could be specified multiple Package Groups, one per line.
For example, "L" series could correspond with "Libraries" group.
For what to do that little supplementary "complication" ?
The Design could be used in more other ways, for example, we can imagine a group "LAMP", which gives you all packages needed for an Apache Web-Server with all the bells.
Last edited by Darth Vader; 12-05-2017 at 03:03 PM.
For this to work the pkgtools should support dependency resolution. They don't and won't.
Let's turn things around. Tagfiles already do a lot of what you propose. They only work in the installer, agreed, but that's where you would use your "slack groups" too.
Why don't you setup a repository (and invite others to assist) where you maintain sets of tagfiles for the most recent Slackware releases? Sets that would ease the installation of a KDE-free Slackware, or a LAMP stack, or a console-only server, or... [fill in the blanks].
For this to work the pkgtools should support dependency resolution. They don't and won't.
Permit me to disagree. Those Package Groups has nothing to do with the Automated Dependency Resolution.
They are just an extension of the actual Design, of grouping the packages in the Package Series, just adding the ability to be specified multiple groups.
And it is very simple: IF the package presents a file "install/slack-groups" it process and register its content in the database, as a new line(s), for example a file containing:
Code:
Libraries
Plasma Dependencies
will result in registration of
Code:
PACKAGE GROUPS: Libraries, Plasma Dependencies
That's all. No automated dependency resolution of any kind.
Quote:
Originally Posted by Alien Bob
Why don't you setup a repository (and invite others to assist) where you maintain sets of tagfiles for the most recent Slackware releases? Sets that would ease the installation of a KDE-free Slackware, or a LAMP stack, or a console-only server, or... [fill in the blanks].
Is worth to do that (or I can do that in a reasonable time) while the internal dependencies of a Slackware release is some kind Black Magic know only by you and our BDFL?
Last edited by Darth Vader; 12-02-2017 at 01:02 PM.
Is worth to do that while the internal dependencies of a Slackware release is some kind Black Magic know only by you and our BDFL?
It's a mistake to think that we know them, or that your simplistic scheme would be able to handle them properly.
What you're proposing is outside of the scope of what the package utilities are designed to do, which is handle installation/removal/upgrade of tar+compression archives and maintain a text-file database of what's currently installed on the machine.
Feel free to develop and maintain a third party tool that attempts to do this, and maintain the dependency databases that it requires, but it won't be done here.
The proposed scheme is intentionally simplistic, to ensure a low burden of its adding, and its purpose is purely informational and human readable, with no handling of that new information registered in database.
How the user use that information?
With a thirdly partly tool? Manually? Is at his choice and abilities.
For example, a die hard user could even do a full install, then can decide to look into packages database, on every file, and to remove manually some particular packages.
You can see it as a way to share an information which you already know (the purpose of that software) at the time of building a package, with your users. Nothing more.
Last edited by Darth Vader; 12-02-2017 at 01:22 PM.
And to continue my arguments, to note that the PKGTOOLS already register the Package Series, sort of.
Code:
PACKAGE NAME: audacious-3.9-i586-1
COMPRESSED PACKAGE SIZE: 480.0K
UNCOMPRESSED PACKAGE SIZE: 2.0M
PACKAGE LOCATION: /usb-stick/slackware-current/slackware/xap/audacious-3.9-i586-1.txz
PACKAGE DESCRIPTION:
audacious: audacious (A relatively powerful media player)
audacious:
audacious: Audacious is a media player, based on Beep Media Player, which is in
audacious: turn based on the X Multimedia System (XMMS). It is used to play
audacious: audio and other kinds of media files. By default Audacious can play
audacious: MPEG audio, Ogg Vorbis, RIFF wav, most module formats, and a few
audacious: other formats. Audacious can be extended through plugins to play a
audacious: number of other audio and video formats.
audacious:
audacious: The webpage for Audacious is: http://www.audacious-media-player.org
audacious:
FILE LIST:
./
install/
install/doinst.sh
install/slack-desc
usr/
usr/bin/
usr/bin/audacious
usr/bin/audtool
...
A snippet from a random package, which shows the (original) location of the installed tarball.
One can write a tool to parse "PACKAGE LOCATION" and to identify the Package Series which hosted this particular package. Or he just can read that information: XAP
Last edited by Darth Vader; 12-02-2017 at 01:52 PM.
Feel free to develop and maintain a third party tool that attempts to do this, and maintain the dependency databases that it requires, but it won't be done here.
This is already done.
This repo has all that's needed. So one can just type
Code:
slapt-get --install-set kde
to install all packages in the kde series. Here I have kde installed but that's what would else be installed, if I use an official mirror as source:
Code:
root[/home/didier]# LANG=en_US.utf8 slapt-get --install-set kde -s
Reading Package Lists...Done
amarok is up to date.
amor is up to date.
analitza is up to date.
ark is up to date.
artikulate is up to date.
audiocd-kio is up to date.
baloo is up to date.
baloo-widgets is up to date.
blinken is up to date.
bluedevil is up to date.
bomber is up to date.
bovo is up to date.
calligra is up to date.
cantor is up to date.
cervisia is up to date.
dolphin-plugins is up to date.
dragon is up to date.
filelight is up to date.
granatier is up to date.
gwenview is up to date.
juk is up to date.
k3b is up to date.
kaccessible is up to date.
kactivities is up to date.
kajongg is up to date.
kalgebra is up to date.
kalzium is up to date.
kamera is up to date.
kanagram is up to date.
kapman is up to date.
kapptemplate is up to date.
kate is up to date.
katomic is up to date.
kaudiocreator is up to date.
kblackbox is up to date.
kblocks is up to date.
kbounce is up to date.
kbreakout is up to date.
kbruch is up to date.
kcachegrind is up to date.
kcalc is up to date.
kcharselect is up to date.
kcolorchooser is up to date.
kcron is up to date.
kde-base-artwork is up to date.
kde-baseapps is up to date.
kde-dev-scripts is up to date.
kde-dev-utils is up to date.
kde-runtime is up to date.
kde-wallpapers is up to date.
kde-workspace is up to date.
kdeartwork is up to date.
kdeconnect-kde is up to date.
kdegraphics-mobipocket is up to date.
kdegraphics-strigi-analyzer is up to date.
kdegraphics-thumbnailers is up to date.
kdelibs is up to date.
kdenetwork-filesharing is up to date.
kdenetwork-strigi-analyzers is up to date.
kdepim is up to date.
kdepim-runtime is up to date.
kdepimlibs is up to date.
kdeplasma-addons is up to date.
kdesdk-kioslaves is up to date.
kdesdk-strigi-analyzers is up to date.
kdesdk-thumbnailers is up to date.
kdev-python is up to date.
kdevelop is up to date.
kdevelop-pg-qt is up to date.
kdevelop-php is up to date.
kdevelop-php-docs is up to date.
kdevplatform is up to date.
kdewebdev is up to date.
kdf is up to date.
kdiamond is up to date.
kfilemetadata is up to date.
kfloppy is up to date.
kfourinline is up to date.
kgamma is up to date.
kgeography is up to date.
kget is up to date.
kgoldrunner is up to date.
kgpg is up to date.
khangman is up to date.
kig is up to date.
kigo is up to date.
killbots is up to date.
kio-mtp is up to date.
kiriki is up to date.
kiten is up to date.
kjumpingcube is up to date.
klettres is up to date.
klickety is up to date.
klines is up to date.
kmag is up to date.
kmahjongg is up to date.
kmines is up to date.
kmix is up to date.
kmousetool is up to date.
kmouth is up to date.
kmplot is up to date.
knavalbattle is up to date.
knetwalk is up to date.
kolf is up to date.
kollision is up to date.
kolourpaint is up to date.
kompare is up to date.
konquest is up to date.
konsole is up to date.
kopete is up to date.
korundum is up to date.
kpat is up to date.
kplayer is up to date.
kppp is up to date.
kqtquickcharts is up to date.
krdc is up to date.
kremotecontrol is up to date.
kreversi is up to date.
krfb is up to date.
kross-interpreters is up to date.
kruler is up to date.
ksaneplugin is up to date.
kscreen is up to date.
kshisen is up to date.
ksirk is up to date.
ksnakeduel is up to date.
ksnapshot is up to date.
kspaceduel is up to date.
ksquares is up to date.
kstars is up to date.
ksudoku is up to date.
ksystemlog is up to date.
kteatime is up to date.
ktimer is up to date.
ktorrent is up to date.
ktouch is up to date.
ktuberling is up to date.
kturtle is up to date.
ktux is up to date.
kubrick is up to date.
kuser is up to date.
kwalletmanager is up to date.
kwebkitpart is up to date.
kwordquiz is up to date.
libkcddb is up to date.
libkcompactdisc is up to date.
libkdcraw is up to date.
libkdeedu is up to date.
libkdegames is up to date.
libkexiv2 is up to date.
libkipi is up to date.
libkmahjongg is up to date.
libkomparediff2 is up to date.
libksane is up to date.
libkscreen is up to date.
libktorrent is up to date.
libmm-qt is up to date.
libnm-qt is up to date.
lokalize is up to date.
lskat is up to date.
marble is up to date.
mplayerthumbs is up to date.
nepomuk-core is up to date.
nepomuk-widgets is up to date.
okteta is up to date.
okular is up to date.
oxygen-gtk2 is up to date.
oxygen-icons is up to date.
pairs is up to date.
palapeli is up to date.
parley is up to date.
partitionmanager is up to date.
perlkde is up to date.
perlqt is up to date.
picmi is up to date.
plasma-nm is up to date.
polkit-kde-agent-1 is up to date.
polkit-kde-kcmodules-1 is up to date.
poxml is up to date.
print-manager is up to date.
pykde4 is up to date.
qtruby is up to date.
rocs is up to date.
skanlite is up to date.
smokegen is up to date.
smokekde is up to date.
smokeqt is up to date.
step is up to date.
superkaramba is up to date.
svgpart is up to date.
sweeper is up to date.
umbrello is up to date.
wicd-kde is up to date.
zeroconf-ioslave is up to date.
0 upgraded, 0 reinstalled, 0 newly installed, 0 to remove, 0 not upgraded.
Done
root[/home/didier]#
But here is what I get if i use the aforementioned repo:
Well, it seems that I get the same output without akonadi.
However it works for a single package, so I am not sure that slapt-get considers the deps as it does when with the option --install instead of --install-set. I will check that if if confirmed make a feature request.
Last edited by Didier Spaier; 12-02-2017 at 02:26 PM.
BUT, that use automated dependency resolution given by "slapt-get". AND, I do not think that it is able to clean "uninstall" the KDE and all its dependencies. There should be the human factor.
Instead, my proposal is just about a simple and the simplest way of extending an already existent feature, to be a help (eventually) for our BDFL to share more easily (and organized) some valuable information with us: the package purpose.
Note that the Slackware already have a way to specify an unique Packages Group: we call this Package Series.
My proposal is just about extending that feature, to have ability to specify multiple values.
OK, if there is no like for the name Package Groups, we can name that Package Series or whatever.
Last edited by Darth Vader; 12-02-2017 at 02:26 PM.
BUT, that use automated dependency resolution given by "slapt-get".
Yes, but what does that change? The hard work (finding the deps accurately) has to be done in all cases, whether to feed a tool or to populate the groups manually.
Quote:
AND, I do not think that it is able to clean "uninstall" the KDE and all its dependencies.
Correct, it can only uninstall a single package or a blank separated list of packages, not a set. In other words there is no --remove-set option.
Last edited by Didier Spaier; 12-02-2017 at 03:54 PM.
Yes, but what does that change? The hard work (finding the deps accurately) has to be done in all case, whether to feed a tool or to populate the groups manually.
There you make a common mistake: you confuse the packages groups with the dependencies and their eventual automatically resolution.
A package group, at least in the concept of RPM or DEB, has nothing to do with dependencies, but instead is an organization of packages depending in their purpose.
Same we do also us, in a hard-coded way, organizing the packages in Package Series, which gives the ability to know an (unique) purpose of a particular package.
Are the Package Series controversial? I do not think so. BUT, they are already a way to specify an unique package group, like I said.
Have no importance that we call it "L" or "Libraries", it is worth that that particular package is part of that group.
Enter that simple extension of PKGTOOLS, where one can specify multiple groups for a particular package, and that information to be registered in packages database, for informational purposes only.
For example, even if you host a package in the L series, knowing well that you add that particular package as a dependency of Plasma, you can add a new line in the "install/slack-groups":
Code:
Plasma Dependencies
The users, even with no additional tools, can literally read that information and can know that that particular package was added for the Plasma wellness and it is one of its dependencies.
In other words: you know the purpose of that package.
Last edited by Darth Vader; 12-02-2017 at 02:57 PM.
...
To extend the PKGTOOLS to handle "install/slack-groups" files, where could be specified multiple Package Groups, one per line.
...
man slackpkg:
Code:
generate-template
This action creates a new template with all official packages that are installed in your system. The tem‐
plate is stored at /etc/slackpkg/templates
install-template
This action install the required template in the system. The template must be in /etc/slackpkg/templates.
If the template "includes" other templates, all of them need to be in /etc/slackpkg/templates. You can
disable the "includes" in slackpkg.conf or in command-line.
remove-template
This action remove all packages that are part of selected template. Be careful, this can put your machine
in an unusable state. The "include" handling can be activated/deactivated in slackpkg.conf or with the
appropriate option in command-line.
BUT, that slackpkg template thing is a system wide feature which marks all installed packages on a template for future use.
Myself, I talk about package groups (or series), as a way to further organize the packages and to explain the purpose of a particular package to users.
Last edited by Darth Vader; 12-02-2017 at 03:22 PM.
Myself I talk about package groups (or series), as a way to explain the purpose of a particular package to users.
Well, you can create /etc/slackpkg/templates/Libs_Used_Only_By_Plasma5.template and list the libraries one per line.
Or Common_libs.template or GTK.template or QT.template. A package can be in more than one template. A template can include other templates, for example GTK will include Common_libs and X_libs.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
