LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Installation time Slackware TAG files (https://www.linuxquestions.org/questions/slackware-14/installation-time-slackware-tag-files-4175649249/)

SCerovec 02-28-2019 05:59 AM

Installation time Slackware TAG files
 
Slackware is best installed full.
If you are new to Slackware you better install it all the first time around.

Some of us, who know and use Slackware for a while now, might have scenarios where installing a heavily pruned system is of interest or of benefit.

So far I've read many things about TAG files but never came to use them.

In requests for current we have come to agreement to explore how useful TAG guided install would be for the day to day users of Slackware and how many users could actually benefit of such a system.

Post your TAG files here, explain what purpose you use them for and cast your vote for the opinion matching your mind the closest.

And please be polite :hattip: in discussing if we would benefit from such a feature or not.

enorbet 02-28-2019 06:24 AM

Since Slackware releases last for years, I see no good reason for me to ever install some form of limited system. I always go Full Recommended Install as it will save me time for all those years of not having to chase down dependencies and this has served me well for ~20 years. It adds up. Additionally, every now and then I will see some app I know little or nothing about and just casually launch it and see what it's all about. There is also a minor safety factor in that if some driver install or tweak borks a WM/DE (rare, but does happen) I can always find one that still works to help me suss out what I did wrong or what failed.

I don't think I can possibly express how grateful I am that Slackware exists. I spend many hours every day on my PC and repeatedly I find myself noting just how good Slackware really is... at least for me. Nothing else quite compares. It's truly in a league of it's own. I love it. It's like an old best friend.

Okie 02-28-2019 06:57 AM

maybe some clever person will build a smart tag generator tool thing that makes it easy do sort it all out, then when you go to install slackware you can just point the installer at your custom tag file and BAM! you got your custom slackware install

Alien Bob 02-28-2019 07:58 AM

Quote:

Originally Posted by Okie (Post 5968117)
maybe some clever person will build a smart tag generator tool thing that makes it easy do sort it all out, then when you go to install slackware you can just point the installer at your custom tag file and BAM! you got your custom slackware install

http://www.slackware.com/~alien/tool...e_generator.sh from years ago.

I should mention that slackpkg knows the concept of "templates" which are functionally similar to tagfiles, but to be used at a later stage in the installation of a system.

Okie 02-28-2019 09:42 AM

Thanks Alien_Bob, that worked good

mralk3 02-28-2019 11:25 AM

Installation time Slackware TAG files
 
As a web developer I prefer the full recommended install. I have done minimal installations but I find that eventually I am missing a package at a later date. Full ends up saving me time in the end.

montagdude 02-28-2019 12:08 PM

I don't ever use tag files. I usually just install everything except for e, f, k, kde, kdei, t, xap, xfce, and y, and then add on whatever I need from there. Usually it is not much, as I get the rest from SBo, Alien Bob, or my own SlackBuild scripts.

Gordie 02-28-2019 12:16 PM

Quote:

Originally Posted by enorbet (Post 5968101)
I don't think I can possibly express how grateful I am that Slackware exists. I spend many hours every day on my PC and repeatedly I find myself noting just how good Slackware really is... at least for me. Nothing else quite compares. It's truly in a league of it's own. I love it. It's like an old best friend.

Man, you have managed to put into a few words what Slackware means to you and also to me.

I only do full installs

igadoter 02-28-2019 12:59 PM

Quote:

Originally Posted by enorbet (Post 5968101)
I spend many hours every day on my PC and repeatedly I find myself noting just how good Slackware really is...

I would use shorter version in my signature. Thanks. Or tattoo on my body. For my girlfriend.

anthk 02-28-2019 01:58 PM

I just install everything except KDE and KDEI. If I need someting from KDE, I'll install kdelibs, oxygen-icon-theme and kde-l10n-es and then install whatever I need. Marble is nice.

ttk 02-28-2019 02:58 PM

"Me too" .. my usual practice is to install everything except kde/ and kdei/.

I've dorked around with tagfiles trying to come up with a "generic do-everything server" that fits nicely on small VM instances, but without much success. Eventually I give up, bite the bullet, shell out $$ for a larger VM instance, and install everything except kde/ and kdei/.

SCerovec 02-28-2019 04:03 PM

I once found it to be advantageous to have a minimal bare install from the slow install media.

Once up and running I installed everything else (as usual).

Could have benefited from less than a, l, and n in that it would save me time.

Other than that, the container installation process could benefit from an tag file as well - the same bare minimum:

To be able to boot, rise the network, be able to ssh into it and wget and installpkg.

A similar tag file could be useful for building a build-root that can bootstrap a build process (the famous circular dependency)

It is very clear to me that the benefiting group is small in the overall community, but had we have it - who knows maybe other users could find benefit in using it too?

Stuferus 02-28-2019 05:09 PM

i normaly install everything besides kde and kdei atleast for server use.. on a desktop i do a real everything install.
so i never needed TAG Files.

SCerovec 02-28-2019 06:45 PM

I hope ARM Slackers come soon :scratch:

ZhaoLin1457 02-28-2019 10:04 PM

Quote:

Originally Posted by ttk (Post 5968353)
Eventually I give up, bite the bullet, shell out $$ for a larger VM instance, and install everything except kde/ and kdei/.

WOW!

That's first time I see someone here agreeing that the lack of modularity of Slackware may result in supplementary costs for particular large VMs needed to install useless additional software.

deNiro 03-01-2019 12:23 AM

Quote:

Originally Posted by ZhaoLin1457 (Post 5968492)
WOW!

That's first time I see someone here agreeing that the lack of modularity of Slackware may result in supplementary costs for particular large VMs needed to install useless additional software.

There is no lack of modularity. Currently, slackware is even modular on individual package level. But I get what you mean.

Now, tag files are only useful at the moment of installation of your system. After that moment, the lack of dependency checking remains, which means that without the knowledge you still have the same problem. So tagfiles are only useful if you have certain knowledge and know exactly what you want to do with a system, so I voted "NO".

I lack that knowledge myself (and also the time to experiment with trial and error method). So when I do an install, I exclude KDE, and KDEI, and only deselect software in the other sets from which I know that they "polute" my start menu. And yes, my install probably contains 85% of stuff I will never touch.

If you want a smaller Slackware installation and easy of use after the installation, your best option is to use Salix. Those Salix guys have done a great thing for the slackware users. If you want mostly just what you need, use debian/devuan. Without knowlegde, or time, the only solution is dependency checking in package management, and Slackware simply lacks that.

ttk 03-01-2019 12:31 AM

Quote:

Originally Posted by ZhaoLin1457 (Post 5968492)
WOW!

That's first time I see someone here agreeing that the lack of modularity of Slackware may result in supplementary costs for particular large VMs needed to install useless additional software.

I wouldn't characterize it as a shortcoming of Slackware. It's a great distribution for building your own thing, better than most distros that way.

If anything, it's a shortcoming of mine that I can't decide what I want with sufficient precision, identify what I need to make that happen, and stick with the task long enough to bring it to fruition.

igadoter 03-01-2019 02:51 AM

Note that sets of packages ha no particular meaning. Installing only some of them does not mean to create some stripped Slackware installation. As well all packages can be put in one common directory. With such scenario tagfiles are tools one needs to create its own custom installation.

SCerovec 03-01-2019 04:34 AM

I begin to realize that that even in web deployment situations one could benefit of a trimmed down installation.

Like have some (3rd) TAG option for an remote_ready system with slackpkg on top of bare so once initiated one can readily add 3rd party packages even, or with sbotools custom built ones.

Add to that the binary dependencies tracking tool one Slackware user posted here...

We could really use such an article on slackdocs ;) ...

baumei 03-03-2019 01:58 PM

According to my recollection, I have never done the 'everything install'.

Very early in my experience with Slackware I created a recipe for the install process, and I kept the recipe in a text-file. Among other things, this recipe had a listing of each package to be chosen using the 'expert' mode of the package selector in the 'setup' script. With each new version of Slackware I would update my recipe. I used my recipe-method for at least a decade.

Then, one year I had more than a few computers on which to install Slackware for similar duties, so I created a set of tagfiles based on my recipe. These days, my recipe is much shorter because the package-list has been replaced with a sentence saying to choose <tagpath> in the package selector of the 'setup' script, and the installation process goes more quickly. :-)

I see the poll says:
Code:

Did You ever need TAG files for marginal instalation cases?
It has been quite a few years since I did an install on what I would consider to be marginal hardware. Back then, I was still using my recipe. So, did I need tagfiles? No. These days, would I use tagfiles for such an installation? Probably; mainly because it greatly simplifies re-installation with a new version of Slackware, or re-installation on a new hard-drive (or a new RAID).

My most memorable example of an install on marginal hardware: I needed a server for DNS, DHCP, and NTP --- and I had an old computer with a slow processor, not much memory, and a small hard-drive. This computer was to be on the public Internet, and to run 24/7. I set it up with no GUI, and only the software needed for the tasks and my administration of it (much smaller attack surface). The old computer did well. For about a decade it cooled off only for power outages which exceeded the ability of the UPS, and for the yearly cleaning (during the scheduled building maintenace when the electricity to the building was turned off). It was rebooted only for upgrades to the kernel, or for upgrades of the Slackware version.

For my non-marginal install jobs: for quite a while I have been using tagfiles for all of them. I intend to keep doing so.

If the the tagfile functionality is ever removed from Slackware, and the replacement is not significantly better, then I would investigate creating an add-on package to restore the tagfile functionality, and publishing it on SlackBuilds.

Would it be useful to people if several tagfile-sets came with Slackware, each to use as the prototype for a particular purpose? Yes, I think so. (Hmm, I wonder if they already are, and I never came across them?)

Thom1b 03-04-2019 01:26 AM

Hi,

When a new slackware is released I always reinstall from scratch with tagfiles.
You can find my custom tagfiles here if it can help. I have a set of tagfiles for my desktop use and another for my server use. I install a lot of packages in l/ serie, probably more than I need but it takes me too much time to choose what I really need specificly.
If I need some x/ packages in my server use, it's because of imagick.

Have a nice day!

Richard Cranium 03-05-2019 07:00 PM

Quote:

Originally Posted by ZhaoLin1457 (Post 5968492)
WOW!

That's first time I see someone here agreeing that the lack of modularity of Slackware may result in supplementary costs for particular large VMs needed to install useless additional software.

I thought what @ttk said was that it was worth the money to get a larger VM than to expend the effort to trim down the install. That's not the same thing as "lack of modularity" unless you define "modularity" as "someone else has figured out subsets of packages for me to do <X> so I don't have to".

SCerovec 03-06-2019 02:07 AM

Can't help but wonder why most voters seem to pick just one option?

I picked two.

bassmadrigal 03-06-2019 02:45 PM

Quote:

Originally Posted by SCerovec (Post 5970696)
Can't help but wonder why most voters seem to pick just one option?

I picked two.

Because I felt only one applied for me. I understand that some would want tag files to allow the installer to support installations other than full, but I personally don't have that need.

igadoter 03-07-2019 03:35 AM

Quote:

Originally Posted by bassmadrigal (Post 5970931)
but I personally don't have that need.

Its good but I just realized that probably personal tastes of all many, many years Slackware users maybe should not influence how Slackware runs - I think that possibly newcomers would find tagfiles convenient way to create installation better suited for their own personal needs - as well it can be kind of esthetic - to not install applications they may consider archaic.

ehartman 03-07-2019 04:53 AM

Quote:

Originally Posted by igadoter (Post 5971114)
newcomers would find tagfiles convenient way to create installation better suited for their own personal needs - as well it can be kind of esthetic - to not install applications they may consider archaic.

Yaeh, but newcomers are more likely to run into dependancy problems as they do not know yet what they will need.

This old-time Linux user in fact doesn't install Slackware all that much (from scratch), I think I last did that with 13.1 (and then I used a full-install and removed afterwards "what I wasn't using"). I even got some "partial packages" install, like Thunar:
I _do_ have the shared libraries, as other components of XFCE use them, but not the executables and/or daemon itself. I never use a file manager and hate "extra daemons" running when I do not need them.

chrisretusn 03-07-2019 06:06 AM

Many, many, many, moons ago, I used the tag files that are part of the installation to select what I wanted. For years now I have opted for the "Full Install".

igadoter 03-07-2019 09:05 AM

Quote:

Originally Posted by ehartman (Post 5971139)
Yaeh, but newcomers are more likely to run into dependancy problems as they do not know yet what they will need.

I agree. This is definitely true for someone who is extensively using SlackBuilds, or is planning to use, from slackbuilds.org. SlackBuilds are looking for only additional dependencies. From that point of view it is more convenient to install everything. I always considered such behavior of SlackBuild scripts as their weakness. Assuming scripts will be able to look for missing Slackware dependencie - it would allow to create much more flexible, better suited systems - based on Slackware. Just having only things I need.

bassmadrigal 03-07-2019 11:17 PM

Quote:

Originally Posted by igadoter (Post 5971114)
Its good but I just realized that probably personal tastes of all many, many years Slackware users maybe should not influence how Slackware runs - I think that possibly newcomers would find tagfiles convenient way to create installation better suited for their own personal needs - as well it can be kind of esthetic - to not install applications they may consider archaic.

My answer to the poll and response to the question were based on the poll's question, asking if *I* ever had a need for tag files. I've never had a need for them, but I understand why some would want them.

I can't imagine many scenarios where it would be beneficial for newcomers to do a partial installation. They'll likely find that things are broken or can't be compiled and then think Slackware is garbage and move away from the distro. For the users who understand Slackware and dependencies, it's probably not as big of a deal that Slackware doesn't include many various tag file options, since they can manage that on their own.

Quote:

Originally Posted by igadoter (Post 5971245)
I agree. This is definitely true for someone who is extensively using SlackBuilds, or is planning to use, from slackbuilds.org. SlackBuilds are looking for only additional dependencies. From that point of view it is more convenient to install everything. I always considered such behavior of SlackBuild scripts as their weakness. Assuming scripts will be able to look for missing Slackware dependencie - it would allow to create much more flexible, better suited systems - based on Slackware. Just having only things I need.

This exponentially increases the difficulty in maintaining a SlackBuild. You'd have to add in a lot of different checks to see if one of the thousand plus packages in Slackware is installed to determine if the program will compile properly. Have a look at Christoph Willing's LibreOffice.SlackBuild for an idea of what every SlackBuild could look like (assuming the various packages would require configure flags).

But these kinds of ideas are really hard to implement in a distro that doesn't provide dependency resolution. It would hopelessly complicate SBo and would require a lot of work to generate the tag files in the first place (to make sure all required dependencies are included and nothing is broken). And how do you determine what type of systems should be included? How do you decide what desktop to include? Browser? Media player? Or should X even be included? Should you include apache? MPlayer? From a distro that's known for including everything and the kitchen sink, you're going to find a vast array of preferences that people would rather have, and you'll never make everyone happy. Then, if you end up not including apache and someone wants to install it, how do they ensure they have all the dependencies?

For someone who is well-versed in Slackware and how dependencies work, it'd likely be relatively easy for them to determine it based on errors when running the command or within logfiles, but for those not familiar with determining that, it will just frustrate them and it could lead to that user not wanting to use Slackware anymore.

SCerovec 03-08-2019 03:10 AM

it seems the place containing TAG files, should start with a big fat README_before.txt it seems?

deNiro 03-10-2019 05:39 AM

Well, I voted no, but I changed my mind. This weekend I tried to do a minimal installation of slackware, where I installed A and N, with the idea to build up a small installation. It did not work well for me. It was not enough to get a system with a working network connection. Before I knew it, I added a few extra gigabytes of stuff. One would think that if A contains the base system, and N the networktools, that there would be a system running with a working network connection. But perhaps it is my lack of knowledge. Though I have been using slackware for years, got openBSD servers installed and debian servers. So I am not a complete computer illiterate.

Compare that to debian, where a minimal install including network and some extra tools, is at least below 1GB. Even a full ubuntu installation with virtualbox and some other software is below 6GB. There is no justification for a desktop user to have an install of 10-12GB, where you haven't even installed any of your software, unless you absolutely want to have slackware installed. Realistically you can assume that the audience, that is interested in slackware, probably chooses it because they want more control with a DIY mentality. But when it comes to the software selection, this part is probably too hard for newcomers. Oldtimers probably have no issues with it because they have been using slackware for years, but I think it scares away a lot of new users, that see that the software sets (a, ap ..etc) in slackware make no real sense to them. Which is a shame imo. An influx of new users keeps a product alive, otherwise it will just die off.

It would not be a bad idea for slackware to have a similar installset like Salix(minimal, minimal+xorg+xfce, full),and then have some sane choices for a dev set ( with c/c++, python,java). That would keep the install size at a reasonable footprint. Salix just does that right, with many other things. Sticking to certain principles and methods that work is a good thing, but becoming stale is not.

GazL 03-10-2019 06:16 AM

Quote:

Originally Posted by deNiro (Post 5972271)
There is no justification for a desktop user to have an install of 10-12GB, where you haven't even installed any of your software

Slackware is not for people who want a minimal install. Your complaint is like criticising a HGV for not being as light as a sports car. Apples and oranges.

LuckyCyborg 03-10-2019 06:19 AM

What HGV? You mean a slow school bus...

And still you wonder why a handful of people bought it.

GazL 03-10-2019 06:23 AM

Heavy Goods Vehicle.
https://en.wikipedia.org/wiki/Large_goods_vehicle

Is HGV a UK only term?

LuckyCyborg 03-10-2019 06:25 AM

Play safe and call it just a "mega-truck" or "heavy truck"

deNiro 03-10-2019 06:53 AM

Quote:

Originally Posted by GazL (Post 5972276)
Slackware is not for people who want a minimal install. Your complaint is like criticising a HGV for not being as light as a sports car. Apples and oranges.

I haven't seen that anywhere in the manual nor on the website of Slackware. Also, there is a lot of gigabytes between a minimal install and 10-12gb. That's why I mentioned Salix way of dealing with this. It's better to explore ideas and keep an open mind, then to just state "Slackware is not for people who want a minimal install". That's just reasoning with blinders on.

GazL 03-10-2019 07:14 AM

Whether the website or docs say it, or not, it is what it is. And what it is, is not designed for a minimal install. Lack of dependency management alone should signal that to you. If you still can't see that then ask yourself why Salix even exists?

allend 03-10-2019 09:56 AM

Quote:

I haven't seen that anywhere in the manual nor on the website of Slackware.
From Slackware-HOWTO on the install media
Quote:

If you have the disk space, we encourage you to do a full installation for
best results. Otherwise, remember that you must install the A set. You
probably also want to install the AP, D, L, and N series, as well as the KDE,
X, XAP, and XFCE sets if you wish to run the X Window System. The Y series is
fun, but not required.
Quote:

It would not be a bad idea for slackware to have a similar installset like Salix(minimal, minimal+xorg+xfce, full),and then have some sane choices for a dev set ( with c/c++, python,java).
Unlike Salix, Debian and others, Slackware has no official binary repository. Instead, Slackware has SlackBuilds.org, which allows a user to download build scripts for third-party software. These scripts are tested and maintained for stable Slackware releases. So installing the development series is required for adding software to a Slackware install. I, like many others, make use of trusted third-party binary repositories to ease the installation of software with lengthy and involved compilation. e.g. LibreOffice, OpenJDK
Quote:

There is no justification for a desktop user to have an install of 10-12GB, where you haven't even installed any of your software
The full install comes with a range of desktop environments and window managers, multiple web browsers, mail clients, IRC clients, editors, file managers, office software as well as server tools httpd, mariadb, mail server, DNS servers, Samba. This provides a solid base on which to build a system tailored to individual needs. When I compare 10-12GB with a working Windows 10 install, Slackware looks measly.
I see this thread as a way to explore the increasing calls for minimal install options for Slackware in specific situations, but the requirements need to be defined. History teaches that people who prune without knowledge of Slackware can get unexpected surprises.

SCerovec 03-10-2019 10:47 AM

I can see the need for a tailored "least MB on disk for working network install" TAG file.
But i just doubt there will ever be "minimal server" or "minimal desktop" - this is and will remain for individual users and fun to read threads here on LinuxQuestions.org.
Looking forward to those :hattip:

bassmadrigal 03-10-2019 08:41 PM

Quote:

Originally Posted by SCerovec (Post 5972356)
I can see the need for a tailored "least MB on disk for working network install" TAG file.

But, to play devil's advocate, how would you deal with installing additional packages since Slackware lacks dependency management?

As I've said before, the people who can deal with Slackware's lack of dependency resolution are perfectly capable of maintaining their own minimal system (although, they may not want to spend the time themselves to create one)... but the people who struggle with not having dependency resolution should not be running a minimal Slackware system. Having that available for new users wouldn't help Slackware, it would lead to many more "reviews" about how difficult Slackware is, how hard it is to add additional software, and how easy it is to break it.

igadoter 03-11-2019 03:05 AM

@bassmadrigal many pieces of Slackware ecosystem are scattered around. Even after installing full Slackware they will have to deal with all what they think is missing. It is in fact very similar task to install only subset of packages to create own installation. Just someone help is needed.

SCerovec 03-11-2019 03:51 AM

Quote:

Originally Posted by bassmadrigal (Post 5972513)
But, to play devil's advocate, how would you deal with installing additional packages since Slackware lacks dependency management?

As I've said before, the people who can deal with Slackware's lack of dependency resolution are perfectly capable of maintaining their own minimal system (although, they may not want to spend the time themselves to create one)... but the people who struggle with not having dependency resolution should not be running a minimal Slackware system. Having that available for new users wouldn't help Slackware, it would lead to many more "reviews" about how difficult Slackware is, how hard it is to add additional software, and how easy it is to break it.

In the defense of the idea (perfectly aware we maybe are dissecting a unlikely scenario):

While i can imagine there will be people who try it only to end up stranded, and things like that happened to me before, the point of minimal install - and use cases - are mainly two:

1. One wants to make a resource limited environment that is therefrom capable to be self-enhanced to an arbitrary level of complexity - the containers and virtual machines folks.

2. One is resource constrained in the installation phase and as soon as the install process is over, and control taken over by an installed system, said discomfort is alleviated - be it drivers, human interface, performance or any other handicap really - the folks on the marginal platforms (ARM, PowerPC, A390?) Slackware has been or is yet to be ported in the future.

Neither of those are people ho want to "fire and forget" the installation, and the big fat warning certainly applies, but still the group i "represent" here might be quite a game changer should Slackware come with some sort of official support or recognition for that niche.

Then there are those (most rare group) who try make the somewhat broader "bootstrap root" - the minimal system of Slackware packages able to compile each and every package of the whole.

I happened to read that thread here on LQ, and couldn't stop to be amazed how arduous that happens to become during some specific stages or advances of the source in question. I imagine those would benefit of having them someone "chewed up" at least the list of what packages are "in" for the time that particular release was current and relevant.

But, yes, we can't (and shouldn't) prevent the stray newbie come across that, tries to use it and come here (or where ever) complaining how it broke his boxen.

Then, again this might offload some of the pressure (and boxen breaking guilt!) -current was under all this time ;) instead.

bassmadrigal 03-11-2019 03:51 AM

Quote:

Originally Posted by igadoter (Post 5972572)
@bassmadrigal many pieces of Slackware ecosystem are scattered around. Even after installing full Slackware they will have to deal with all what they think is missing. It is in fact very similar task to install only subset of packages to create own installation. Just someone help is needed.

True, but almost all 3rd-party solutions will provide some sort of dependency list on what is required to ensure that software runs properly on Slackware (although, these lists are only for other 3rd-party packages and don't include any official packages, since they typically only support full installs).

The problem is if they are provided with a minimal install (and what is considered a minimal install is a discussion in and of itself) and they want to install another official package, how are they going to know what other software it might depend on? Slackware doesn't provide required dependencies for packages, so there's no easy answer beyond searching unofficial resources (I know Salix provides a dependency list) or digging down and figuring them out themselves (run the program and hopefully decipher the output to find what program(s) are required to properly run it).

bassmadrigal 03-11-2019 04:06 AM

Quote:

Originally Posted by SCerovec (Post 5972578)
While i can imagine there will be people who try it only to end up stranded, and things like that happened to me before, the point of minimal install - and use cases - are mainly two:

1. One wants to make a resource limited environment that is therefrom capable to be self-enhanced to an arbitrary level of complexity - the containers and virtual machines folks.

2. One is resource constrained in the installation phase and as soon as the install process is over, and control taken over by an installed system, said discomfort is alleviated - be it drivers, human interface, performance or any other handicap really - the folks on the marginal platforms (ARM, PowerPC, A390?) Slackware has been or is yet to be ported in the future.

Resource limited devices (and by "resource", I only mean storage space, since nothing else will be run unless the user runs it themselves) are becoming less and less frequent. Yes, they still exist (and are probably still being produced), but with how frequent they are (and the users desiring to run Slackware on them), it is an extremely small group (even by Slackware standards -- in comparison to usage by the "big" distros like *buntus, Debian, Fedora, Arch, etc).

Quote:

Originally Posted by SCerovec (Post 5972578)
Neither of those are people ho want to "fire and forget" the installation, and the big fat warning certainly applies, but still the group i "represent" here might be quite a game changer should Slackware come with some sort of official support or recognition for that niche.

But does the group you "represent" only run devices with limited harddrive space or are they more driven towards the "only install what I use" mentality. That's a fine mentality to have and works great with many distros, but that mentality becomes exponentially harder when you use a distro without dependency resolution. As I briefly mentioned in the above thread, what is considered "minimal"? Is it just bootable? Bootable with networking? Bootable with X? Bootable with networking and X? If X is included, what WM/DE should be included? Some are perfectly happy with a basic WM like Blackbox, where others would prefer a more robust system like XFCE, while others would only choose KDE. And if we go back to what should be supported, are we shooting for a "desktop" (bootable, networking, X) or a "server" (bootable, networking, LAMP), or something in between? And what if someone wants a minimal server that provides X?

Pat has never wanted to state what Slackware should be used for. It is equally setup for both desktop and server usage. If you take some of those away, the users who want a mix of both (but "minimal") suddenly have to install software beyond what the "minimal" system contains, but then Slackware doesn't provide dependency resolution, so installing something new comes with potential problems.

Do you really think that users that aren't capable of slimming down Slackware themselves are capable of building it up from a minimal install to a working result with official packages?

Not to mention the extra burden on Pat himself to ensure that everything included in a minimal install works properly and that he stays up with the required dependencies as -current moves along its development track.

SCerovec 03-11-2019 03:24 PM

I'm glad you have brought that up.

in that thread where the containers and VM where discussed, and some other threads too, it seems, a quite universal conlcusion was reached of what belongs to the "minimal" install.

The system has to be able to perform only the following tasks:
1. boot (obviously)
2. bring up networking and serial ports if present
3. enable a remote login (be it via net & ssh, or via serial port)
4. have one tool that enables download from network (curl? wget?) via a supplied URL
5. have tools to install an locally referenced package

And that's all - eventually a bare minimal text editor - just to not use ed.

it fits about 128MB really

----

There is currently a trend to make ever more RAM constrained specialized ARM SBC systems that actually fall well within the territory where Slackware excels - LAN routers and servers.

One of them being 256MB ram falls just short of being able to run an Slackware install, for instance, but boasts an quad 1.2GHz CPU and twin Giga LAN ports. Its worth nothing that Slackware runs effortlessly once installed on such a machine - provided you serve IMAP and SAMBA without X.

----

The virtualization crowd really wants a "seed" - a same barren setup that once cloned can be custom fitted with whatever - emphasis on smallest memory footprint as it will be run in great many numbers. They then custom tailor scripts that install whats needed per use basis. And whatnot. Just something as barren as possible still able to log into and run #slackpkg install-new

---

All I say is, we're talking of an list of max 20-30 packages that, once established, isn't drastically changed across many releases. The lists should be answering "what can we omit and still be able to acquire a package and install it?".

bassmadrigal 03-12-2019 10:16 AM

Quote:

Originally Posted by SCerovec (Post 5972790)
in that thread where the containers and VM where discussed, and some other threads too, it seems, a quite universal conlcusion was reached of what belongs to the "minimal" install.

The system has to be able to perform only the following tasks:
1. boot (obviously)
2. bring up networking and serial ports if present
3. enable a remote login (be it via net & ssh, or via serial port)
4. have one tool that enables download from network (curl? wget?) via a supplied URL
5. have tools to install an locally referenced package

And that's all - eventually a bare minimal text editor - just to not use ed.

it fits about 128MB really

But then comes the rest of what I mentioned... how many people will be happy with that minimal install? Very few. Almost everyone will need to install additional software, and without dependency resolution, a lot of people will become frustrated very quickly.

Quote:

Originally Posted by SCerovec (Post 5972790)
There is currently a trend to make ever more RAM constrained specialized ARM SBC systems that actually fall well within the territory where Slackware excels - LAN routers and servers.

One of them being 256MB ram falls just short of being able to run an Slackware install, for instance, but boasts an quad 1.2GHz CPU and twin Giga LAN ports. Its worth nothing that Slackware runs effortlessly once installed on such a machine - provided you serve IMAP and SAMBA without X.

And this is a perfect example of one of the many misconceptions of minimal installs. Installing less has absolutely nothing to do with RAM usage. That's only based on what you run.

Quote:

Originally Posted by SCerovec (Post 5972790)
The virtualization crowd really wants a "seed" - a same barren setup that once cloned can be custom fitted with whatever - emphasis on smallest memory footprint as it will be run in great many numbers. They then custom tailor scripts that install whats needed per use basis. And whatnot. Just something as barren as possible still able to log into and run #slackpkg install-new

This already exists in Slackware with lxc templates (see /usr/share/lxc/templates/lxc-slackware -- the below is from 14.2, the list would be different on -current):

Code:

aaa_base
aaa_elflibs
aaa_terminfo
bash
bin
bzip2
coreutils
dcron
dhcpcd
dialog
diffutils
e2fsprogs
elvis
etc
eudev
findutils
gawk
glibc-solibs
gnupg
grep
gzip
iputils
libunistring
logrotate
mpfr
net-tools
network-scripts
ncurses
openssh
openssl-solibs
pkgtools
procps-ng
sed
shadow
sharutils
slackpkg
sysklogd
sysvinit
sysvinit-functions
sysvinit-scripts
tar
util-linux
wget
which
xz

Quote:

Originally Posted by SCerovec (Post 5972790)
All I say is, we're talking of an list of max 20-30 packages that, once established, isn't drastically changed across many releases. The lists should be answering "what can we omit and still be able to acquire a package and install it?".

And all I'm saying is we're talking about adding a minimal install to the installer, which will invite new users to use that option, which will undoubtedly lead to many frustrated users (in reality, how many users do you think want a system that minimal?). For the users who are able to run minimal installs and add the software they require, it wouldn't make a huge difference if it's in the installer or something they do manually.

ponce 03-12-2019 01:19 PM

Quote:

Originally Posted by bassmadrigal (Post 5973027)
This already exists in Slackware with lxc templates (see /usr/share/lxc/templates/lxc-slackware -- the below is from 14.2, the list would be different on -current)

FYI, the new lxc template I had experimented last time on current with needed some additions (YMMV)
Code:

@@ -5,11 +5,14 @@
 bin
 bzip2
 coreutils
+cyrus-sasl
+db48
 dcron
 dhcpcd
 dialog
 diffutils
 e2fsprogs
+elfutils
 elvis
 etc
 eudev
@@ -17,17 +20,25 @@
 gawk
 glibc-solibs
 gnupg
+gnutls
 grep
 gzip
+iproute2
 iputils
+libcap-ng
+libffi
+libmnl
+libtasn1
 libunistring
 logrotate
 mpfr
 net-tools
+nettle
 network-scripts
 ncurses
 openssh
 openssl-solibs
+p11-kit
 pkgtools
 procps-ng
 sed

everyone has his own idea of what a minimal install is and which things are needed in it so, IMHO, it hasn't much sense to ship templates in the distribution (that need to be maintained also on the same stable release: I remember, for example, wget in /patches needing additional dependencies) if who uses them still has to manage solving dependencies himself, like bassmadrigal says.

when I plotted down the list of packages (mainly stolen from vbatts :) ) for the original lxc-template the only criteria I used was, like SCerovec said above, to have an usable slackpkg to be able to add things easily afterwards, but this still doesn't give the user exactly what he wants: the moral of the story is "my minimal install is different from yours".

that said this obviously is not meant to discourage any eventual third-party effort to ship slackpkg templates or tagfiles somewhere where who likes to experiment with them can grab them, or contribute (who said a public git repository?): if someone is interested, please do. :)

SCerovec 03-12-2019 01:35 PM

This is exactly what i was hoping for :hattip:

We might actually try run a public repository and have like few of the mentioned options hosted in there.

After a while it would certainly boil down to either there is a need for infinite number of versions, or there is really one file that could fit many most use cases best. Os somewhere in between :scratch:

And after that while, we might eventually consider if there is any worth of endorsing that ever into Slackware


All times are GMT -5. The time now is 01:56 AM.