Indeed, Qt is not only needed for KDE. Maybe it was a bad example. However, the L series are a lot of libraries that are used only by KDE today. Or others that are used only by GUI.

What I want in the future in Slackware?

First, a clear series division between console applications, the graphic medium / light, such as XFCE, and KDE. What's the point to install akonadi, virtuosso or strigi, into a LAMP server, for example?

Secondly, I would like to perl, python, ruby to be moved from the D series. You need them in a server, but a very good rule of an admin is 'DO NOT INSTALL THE TOOLKIT INTO A SERVER! NEVER!'. I would like that I would not touch the D series, when I make such an installation.

Thirdly, I subscribe to introduce dependencies, for the information, of course, not as automatic system. That would ease my work very much. For that, one of company policies, where I work, is "any unnecessary package is a vulnerability, install only what is necessary." Therefore, when I install an application into a server, I need to find dependencies, to avoid any unnecessary package.

0 members found this post helpful.

And another idea ...

As we know, SlackPkg supports Templates. How about an integration of this feature in the installer and have a punctual installation packages for different targets? Maybe something like:

* A stupid console.
* A Mail server.
* A LAMP server.
* An light desktop with XFCE.
* KDE with all the bells.

1 members found this post helpful.

I had anki running in 13.0 and it runs fine in 13.1 as well. I haven't tried installing it system-wide and just ran the 'anki' python script in the extracted source archive but there's nothing insane about the two setup.py files it tells you to run so it would probably work as well. Slackware doesn't arbitrarily split applications into runtime and -devel packages so any python headers you need should be installed as far as I know...
Slackware 13.1 ships with Python 2.6.4 so the first and last items are satisfied. 13.1 ships with PyQt 4.7.2 so item 2 is satisfied. SQLAlchemy and simplejson are available from slackbuilds.org (and no python recompilation or any such thing is needed).
The only thing that is not available from slackbuilds.org (and does not ship with Slackware) is pyaudio (python-beautifulsoup is known as BeautifulSoup at SBo), so you'd have to get it elsewhere or install it manually. That is of course an optional dependency (which itself depends on PortAudio, which is available at SBo).

If something's not working, I don't think it's a python headers issue...

1 members found this post helpful.

Is the problem that python headers are not included or only that certain apps can't find the headers?

That is an idea to consider. That can be challenging because there are so many options and cross-options that could be listed.

Yet I hope that if Pat decides to offer such options he always installs all development related packages as part of the default.

One reason I stick with Slackware for my personal use is Pat does not split packages into user and development packages. I hope he never does. I like all-in-one. Often I test other distros in VirtualBox, which to be useful requires the VirtualBox guest additions, which to compile requires the kernel headers. To a high degree most distros do not include the kernel headers and that requires additional steps to download. Frustrating in a 800x600 screen. I have been testing Current in a virtual machine and I never blinked about installing the guest additions.

Debian based systems are frustrating in this way. Installing the VirtualBox guest additions is a mini-circus because the development build system has to be installed as well as kernel headers.

In this day and age of testing in virtual systems, including basic build systems and kernel headers should be automatic for any distro, even if that adds another 50MB or so to the CD/DVD size.

This is true too for installing any software that requires the kernel headers, such as the nvidia drivers or VirtualBox.

I agree with this idea. Maybe not the Qt specifically, but other kde-specific libraries definitely.

Does anyone know why does rc.M have those lines for updating mime db, ldconfig, font cache and those gtk stuff run on each reboot? I am talking about the situation described here

My only guess is that those were added at some point in order to make sure they were applied to all applications without rebuilding them and gradually adding a post installation script to the packages thats needed in order to take advantage of them.
Pkgtools are perfectly capable of handling post installation scripts in doinst.sh but i dont think i see them gradually get added there if that is indeed the case.

Boot time is delayed significantly for absolutely no reason, at least from my point of view.
I doubt there is even one person who needs those to run during every system boot.

Actually i just thought of a case where a person will need those to run on every boot.
Its a person who (re)boots once per Slackware release doing a clean installation each time.

edit: Another use case where these might be needed. Probably a more common one.
When someone builds packages from source and neglects or doesnt know he has to run those himself.
All packages from SBo contain post installation scripts for those so it shouldnt be a problem then.

A post-installation script won't work very well if the commands that it needs to use are in another package that isn't installed yet. Rather than introduce install-order dependencies, we make sure those things are run at boot time. Now, I can't say that I'm 100% happy with it (and I'll avoid ranting about registry-like systems), but I would rather have it take 10 more seconds to boot if it means that a few percent of machines out there will catch a problem at boot and work fine when they otherwise would have suffered strange problems.

5 members found this post helpful.

Well, my boot sequence always goes like this.

Power-on PC...
wait...
enter luks password for rootvg.
Go to kitchen and power-on kettle...
wait...
Come back to waiting login prompt with steaming cup of coffee in hand.
Use steaming cup of coffee to Power-on brain.

One thing that could be done to speed up the boot would be to signal to the boot scripts whether running the updates is required, in much the same way as fsck doesn't need to run when the filesystem was unmounted cleanly. Could be something as simple as touching a file whenever anyone runs one of the package tools commands and have the boot script check for it's existence, run the updates if it's found and then delete it once the updates have been run.

Having said that, as long as Slackware boots faster than my kettle boils, I don't really care.

I wrote that article soon after Slackware 12.1 was released. When those tasks were added to rc.M in 12.1, they were run sequentially. The increase in boot time was noticeable. Search the forum for those original discussions.

I go through periods when I tend to reboot often because I experiment often. I never explained that in my original article. Many people boot once a day and the increase in boot time with 12.1 was not painful.

Starting in 12.2 those tasks remained in rc.M but were run in the background. That helped restore the boot time. I never added that information to the original article.

The original article therefore implied those tasks remained as a cause of a perceived slow boot time.

A handful of people who tinker might want to move those tasks from the boot sequence. Most folks won't notice or care.

I updated the article to avoid those misperceptions.

3 members found this post helpful.

Have at the time of installation of Slackware, the option to use lilo or grub ...

thanks

grub 1 needs a ton of patches and grub 2 is still marked as "Enhancements to GRUB are still being made, but the current released versions are quite usable for normal operation." Lilo just works. Why change?

1 members found this post helpful.

Hi,

Personally, I prefer 'lilo' for Slackware. If it ain't broke, don't fix it!

1 members found this post helpful.

Hi :-)

I'm not saying to change the lilo by grub, but to add.
Those who prefer lilo, use lilo, those who prefer grub, grub use ...

thank

ps: inclusive, would be more democratic ;-)

Furthermore, it would be easier for users of Slackware (Slackware which has as its default distribution), which want to install or test other distributions that use grub as boot loader. ... eg:Fedora 14

Of course I think the maintainers of Fedora 14 should also give the option to install lilo ...

Fedora cited as an example only ...

thanks