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. |
Quote:
samac |
Quote:
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. |
Quote:
At the same time without akonadi installed kmail won't even start. |
Quote:
|
Quote:
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. |
Quote:
|
Quote:
|
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: Code:
firefox -app /home/didier/conkeror/application.ini & |
Quote:
Building a seperate xulrunner package would mean both apps would use the same engine. |
Quote:
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. |
Quote:
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 |
Quote:
|
All times are GMT -5. The time now is 10:41 AM. |