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.
Because there are more and more packages coming with Slackware distribution, I have a proposal to add sub-classifications for the package selection during installation.
Why? Because I usually do the customized installation for my machine. I hope my system clean and tidy, and not having some programs that I will never use them. Thus, I always spent 30 minutes or more for un-selecting what I don't want to install. It's so time-consuming. Based on the motivation, I hope the packages classification could be more delicate, especially the AP class packages.
For example:
In AP class, it can be classified into Email Related, News Related, Audio Related, and so on. Like this:
[*]+Email Related
-[*] pico
-[*] mailx
-[*]...
[ ]+News Related
-[ ]...
-[ ]...
[ ]+Audio Related
-[ ]...
-[*]...
I guess this could reduce the time for selecting packages. For me, I never use the news and command-line audio player. Thus, I can un-select them all in a quick way, and don't have to check each program and read its description for un-selecting. I thought it would save the time while installation.
The above is just my humble opinion. I just want to know if there is anyone who have the same with me. Maybe we can provide a suggestion to the develop team.
Normally I do a full install (since that one gets me started quickest) and remove unwanted packages after.
A more delicate menu certainly could help, but then -given that quite a few X applications are frontends to command-line tools- some dependency checking should be in place somehow.
Not that I see this as "the" solution, but I recall cygwin giving a decent approach on their install... A tagfile generated out of the choices for later use (elsewhere) and I'd love the slackware installaten even more than I already do.
I think this could be a useful idea, something like the kernel menuconfig dialog, only for packages. Though, I think the idea would be more useful for a modern distro that holds everything and the kitchen sink, there are a couple packages I would like to remove from my slack install, but just never really bothered with tagfiles or removing them afterward.
When you look at the SlackBasics page I linked to, you'll find a script to do just that.
whoops, years of slack experience and it turns out I'm still the noob here ;-) However, I was more referring to the installation process saving this file for you.
As mentioned like the kernel compile menu (make menuconfig) and then also in a style "make oldconfig", asking you for new / changed options. That really would be sexy :-D
In AP class, it can be classified into Email Related, News Related, Audio Related, and so on. Like this:
[*]+Email Related
-[*] pico
-[*] mailx
-[*]...
[ ]+News Related
-[ ]...
-[ ]...
[ ]+Audio Related
-[ ]...
-[*]...
I guess this could reduce the time for selecting packages.
I don't like your suggestion. It makes things much more complex when it comes to the installer.
The only way i could see this being achieved and still keeping things simple, is having eg. AP1, AP2 etc containing grouped software like it was in the past. But i seriously doubt its useful.
As it's already said above the preferred method for custom non time consuming installations is to use tagfiles.
I suggest you use Alien_Bob's tagfile generator script to get a set of tagfiles of the currently installed Slackware packages.
PS. you need to have a Slackware tree somewhere in order to use the tagfile generator script.
Also this thread might be useful http://www.linuxquestions.org/questi...lready-493159/ (copied from the above script).
I've done some study about tagfile. But, it only works to the corresponding version. I mean if I have prepared the tagfile for Slackware 12.2 installation, but how about the installation of the incoming version? I still have to spend much time to create a tagfile for the new version of Slackware. I guess the tagfile approach is fit for lots of same installation in an organization or a computer classroom.
Due to my job, I usually have to setup a new machine, and my case is not for the massive installation. In my work, the new machine would be a computation node in a cluster, or a data-storage node in a grid. Perhaps it would be the performance testing platform, my personal work station, or something for other purpose. If I adopt the tagfile approach, I have to prepare many editions of tagfile for many purposes, respectively. If there is a more delicate menu, the installation for the first time would save much time. In the afterward installation, it would not take much time even though I don't have the tagfile.
About the package dependency issue, I though it would not be a problem. Slackware always leave the job to the user in the past. The user can decide want s/he want and always know what s/he is doing. Hence I guess the dependency checking would be ignored if adopting the delicate menu approach.
The delicate menu is just a possible workable proposal for me. Maybe there are other solutions instead of the delicate menu approach or the tagfile approach. I'll think about everyone's suggestion and opinion again.
Another option would be to use Alien Bob's mirror-slackware-current.sh with an excludes.txt file. I do this to exclude everything that I don't want, and this can be done down to individual files. I started a thread about this that might be useful, here is a link.
I wonder if it would be decent dependency resolving workaround for extra repositories through symlinks to the dependencies of a package so an app and all its dependencies could be installed by 'upgradepkg --install-new dependent_apps_directory/*.txz'.
I am not so much into computers to tell if it is a stupid idea or an old one or both.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.