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. |
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]. |
Quote:
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 Code:
PACKAGE GROUPS: Libraries, Plasma Dependencies Quote:
|
Quote:
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. |
Look, Patrick...
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. |
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 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 |
Quote:
This repo has all that's needed. So one can just type Code:
slapt-get --install-set kde Code:
root[/home/didier]# LANG=en_US.utf8 slapt-get --install-set kde -s 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. |
Yeah, Didier...
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. :D 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. |
Quote:
Quote:
|
Quote:
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 In other words: you know the purpose of that package. |
Quote:
Code:
generate-template Cheers |
Yeah, Ivandi...
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. |
Excuse my ignorance, but it is hard to believe that the Slackware maintainer himself has no clue why he added a package to distribution...
|
Quote:
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. Any volunteer to maintain a set of templates :D Cheers |
Quote:
|
All times are GMT -5. The time now is 08:51 AM. |