A proposal: Classification of package install
 

Hi, folks.

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.

Thanks for your reading. :)

It sounds like you always leave the same packages out of your installations. Slackware has a mechanism to automate that. It's called "tagfiles."

http://slackbasics.org/html/chap-pkg...gmgmt-tagfiles
http://slackware.oregonstate.edu/sla...lackware-HOWTO
http://www.slackbook.org/html/packag...-tagfiles.html

Therefore, I think a simpler solution and more versatile solution might be a place exchange tagfiles. This very thread, perhaps?

(No, I'm not going to start. I alway do full installs).

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.

When you look at the SlackBasics page I linked to, you'll find a script to do just that.

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.

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

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.

Thanks for everyone's discussion. :)

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.

samac

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.

"yes"

;-)

Aargh! I knew it! :)