1) Updating a multi-lib install is a pain, as you have to find out what 32-bit packages need updating and run the updated packages through the conversion script before installing them.

2) A stripped-down KDE version like the kde-base package in Gentoo. It doesn't install Akonadi, uses 150-200 meg of RAM, and isn't lacking any features that I need. I think people would appreciate less bloat; I've seen a lot of people going to XFCE for this very reason.

3) I understand not everyone is a fan of 64-bit multilib, but it would be nice to provide this as an option in the installer. I always come across something that needs 32-bit compatibility like flash, acroread, wine, and several games. Also, creating an environment variable that tells Slackbuilds that you have a multi-lib install would be nice: then I wouldn't get a pure 64-bit Nvidia driver install and wonder why my 32-bit game doesn't work.

To the guy recommending Arch: I thought about trying it until I read that every package is bleeding edge, so you end up being a beta tester of sorts. People on various forums seem to dread updating their Arch systems as they tend to break. For me, I would prefer a distro maintainer to pick the latest stable versions of packages for me so I have no problems with updates breaking my system. I also prefer adding packages to a base install instead of getting everything like a default Slackware install gives you, but I don't see it as a big deal. You can always remove packages, and if you don't like the stock mplayer build for example you can always tweak the Slackbuild and replace it.

1 members found this post helpful.

Only for not spelling "probably" properly

samac

Instead, I appreciate that Slackware packages be not stripped down. For instance Slackware packages for mozilla-firefox do include the internal xulrunner engine ; some other distribution's packages do not. And I appreciate that the -dev portion of applications, whenever applicable, be included as well.

If you want to get rid of akonadi, it's just a removepkg away.

And still you can make you own stripped down package: just edit the provided slackbuild, tune the configure options and run it again.

Hey, is it possible to recompile kde-4.4.3 without akonadi? It gives an error upon every boot, so that i have to launch kmail twice, because closing akonadi error message also closes kmail at first launch.

At the same time without akonadi installed kmail won't even start.

This just makes it more time-consuming (and annoying) to have to compile/install xulrunner if you want to install other gecko browsers (like conkeror). This is one of the few instances that I would prefer package splitting.

+1 on that. I have requested this from Pat, and i bet other people have too.
His reply was that he wont be doing that cause 32bit ships the official binaries from Mozilla.

I would also like a split seamonkey as well (seperate nss & nspr) but last time i requested this seamonkey-solibs was born, so i am reluctant to request such things again.

If only slackware also send optimized distros (official if possible) to specific archs and not only i486 then it will also be a +. There's a way to recompile all the packages in Slack but that will take time. More time compared to Gentoo since you still have to think about the dependencies.

I couldn't find any information about Conqueror (guess you didn't mean konqueror, as it uses khtml, not gecko, as its rendering engine). Could you provide an URL or pointer ?

Anyhow a slackbuild for xulrunner is available @ slackbuilds.org.

The inconvenience of stripping xulrunner from firefox is that then you can't run an application for xulrunner with "firefox -app appname", which is possible since firefox 3 if it is shipped complete.

Conkeror, not Conqueror.

Thanks to sahko and T3slider for correcting my typo.

Out of curiosity I just downloaded a snapshot of conkeror in my $HOME, untarred it and launched it that way:It worked, of course because the Slackware package for Firefox does include an internal xulrunner engine, as it should

You actually have 2 xulrunners cause seamonkey includes its own version as well.
Building a seperate xulrunner package would mean both apps would use the same engine.

I will soon have 3 xulrunners then, as I plan to install a standalone one

I don't see that as an inconvenience, as I have enough space on disk.

I stand by my opinion: I prefer not split packages, even at the expense of some more space needed on disk.

For instance I like the package for vlc provided by alienBOB, as it includes all the needed dependencies. I don't care that some be already available in my system, I can live with duplicates.

The lesson with VLC (and other pre-packaged multimedia software) is that there are strict dependencies on the versions of supporting libraries. The *ubuntu people usually learn this the hard way; when they upgrade their ffmpeg or x264 packages, several other programs will break - like VLC. Their forums are full of complaints about this dependency hell.

Therefore, adding the support libraries statically to the main VLC package has the advantage that the situation on-disk may change (you add, remove or update your multimedia libraries at will) but the Slackware VLC package is immune to those changes and will continue to function. You'll get a fat package (if you look at the build script, actually over 40 different source tarballs are being used) but I don't care about that.

Handbrake (the video transcoder) adds its support libraries in a similar way (the developers want to control exactly which software and patches their program is using - saves time on support questions).

There is a big thread on ubuntuforums.org about building VLC development snapshots - the procedure is based on how my SlackBuild script adds static libraries... because people are affected negatively by the "medibuntu" packaging disaster. Very funny to read, and confirmation that I follow the right path.

Eric

1 members found this post helpful.

You're right; uninstalling kaffeine-mozilla solved the stability issue. I'll file a bug report, but in the meantime does somebody know of an mpeg plugin for Firefox that works?