im from the gentoo crowd, recently i realized how most of the times i really dont need to compile things from source...
still, i would like to do it every now and then, so my question is:
is source-compiling a realistic possibility in slackware, how friendly is the environment for this?

also, how developed are the current repos, and are there large community repos also, to go with that?

general answers of that sort from long experienced users(specially) would be great.

regards,

gforum.

You should check out SlackBuilds.org for community build scripts. The build scripts for the official Slackware packages are in the source directories (here is Slackware 12.1 source dir).

It is extremely easy to compile software from source on Slackware - easier than some distros. The reason for this is that almost all the libs you need are included and also Slackware uses vanilla software. You don't have to wait for/create vendor specific patches. You do have to mind your dependencies, though. Thankfully, the SlackBuilds on Slackbuilds.org (SBo) always tell you what you might need. Upstream READMEs, etc are usually enough as is.

Overall, the repo is still not as big as debian's (community or official), but it is very easy to write your own SlackBuilds for instance. SBo has a HowTo.

so basically, the system is not stupid and slackbuilds.org is THE sourcecode-to-compile center/community source.(where you go if you want to compile).
also... how clean/easy to maintain is the system(im sure ill miss 'source /etc/profile', and env-update, etc... -gentoo stuff)?

the main reason as to why i dont like binary-only distros like debian, is that they leave a mess behind... sometimes you instal things and then when removed , they many a times dont really remove everything, etc...

keeping a system that is clumsy like that, clean, is hell... >.<
in my view anyways.

also, how 'bleeding edge' is slackware really(usually anyways)?
im not sure what mean by "Slackware uses vanilla software"...
and can u tell me a bit about your everyday experience with the package manager, and its 'efficiency' and easy of use?

thanks in advanced,

lots of Qs i know. ^^

Slackware isn't bleeding-edge, there are no automatic updates. So what exactly do you mean by "maintain"?

Slackware "package manager" don't have dependency checking, so everything is pretty clean and under your complete control.

It isn't bleeding edge. Slackware always was aiming at stability, not latest version number. (newer software == more bugs)

Means "Uses nearly unmodified source from original developers".

Everyday scenario #1:
1) Install package. (download fron linuxpackages)
2) Use it.
Everyday scenario #2:
1) Compile stuff from source,
2) make package (manually, or with src2pkg or with checkinstall, or using "Slackbuild").
3) install package you made
4) Use it.

I think you should install system, read documentation for a week (or two), and everything will be pretty clear to you. So far questions are pretty basic and you could quickly find answers yourself.

yes... but what i mean was... if i try to remove something that i had installed completely, will it really remove everything or leave its little puppies behind like debian(apt) does.

and also, if i compile something, do slackbuilds help me remove it later also, or do i have to manually delete stuff?

thats what i meant by maintain and my main questions about the package manager i guess(day-to-day use)...

finally, so you said there are not automatic updates, then that means you have to update things yourself, and when they are in the repos you can update it(i assume that there is a -update --world command, or the likes though...), if so, then its just like gentoo.

thanks for the answers guys ^^.

cheers

Anything that was in original package will be removed. Anything that wasn't in original package - won't. I.e. if you created new file in some directories that were stored in package, it won't be removed. The only trails (I know of) package may left behind are settings in your home directory and it'll store one file in /var/log/removed_packages. file will be named something like "sh-4.3.2-i486-2-upgraded-2008-06-16,09:50:14" and will contain listing of all files that were in package. Those can be safely removed.

Slackbuilds don't delete stuff. They are used to create packages and only to create packages. Once package is created, it can be installed/removed using installpkg/removepkg, slackbuilds aren't needed.
So you don't remove programs with slackbuilds, you do it with removepkg.
list of all installed packages is available in /var/log/packages/ (one file per package, take a look yourself). Please notice that "package manager" don't use arcane formats. List of installed packages is a directory with human-readable plaintext file. Package itself is simply *.tar.gz archive of files that are installed by package into root directory plus some install/remove scripts, if they are required. All this is can be easily modified by hand, if you want it.


You can update things manually by compiling packages from source. Also every next Slackware release contains upgrade instructions.

There are no repos of extra software, and the packages in each Slackware release are updated ONLY if there are security issues (or very rarely because of bugs). Pat is pretty good at releasing updated packages in a timely manner if there are security issues, but other than that don't expect to get the latest version of a package unless you want to compile it yourself. Of course, if a whole new Slackware version is released, you can upgrade to that -- but Slackware releases don't come out every day (or every month), and there is no regular release cycle (a Slackware version is released when it's ready). You *could* stay *relatively* up to date if you want to run -current, but that is really just for testing and stability cannot be promised when running -current (though it's still usually pretty good). Though, in my opinion, there isn't always a good reason to get the latest version of a package other than to say you have it. As long as it works, and there are no security issues, why do you need a newer version? That seems to be Pat's opinion as well -- so if you want bleeding edge stuff, you're using the wrong distro. Slackware is stable and performs as you would expect it to -- and that comes at the sacrifice of using older, stable versions of software.

If a security update of a package IS released, it will be at your favourite Slackware mirror in the patches/ directory. You could use rsync to keep up-to-date with security updates (see Alien Bob's script if you want), or you could sign up for Slackware's security advisories mailing list (or both). You could also use slackpkg if you want a *more*, but not completely, automated solution that will download packages for you (but I'm not the best person to talk about slackpkg since I have never used it).

There are UNOFFICIAL repos out there, such as slackbuilds.org (which maintains only SlackBuilds that you use to compile the application yourself), Alien Bob's repository, rworkman's repository, slacky.eu and linuxpackages.net. I would trust the first three 100%, slacky.eu 50% (but I'm paranoid), and linuxpackages.net 10% (I don't use their packages -- they often don't include SlackBuilds, so you have no idea how they were built and you're using blind faith that they will work properly. Also, some packages are built on unclean systems with questionable dependencies. There ARE reputable packagers at linuxpackages.net, but finding them takes experience).

If you want dependency resolution, you can use something like slapt-get with a repository like slacky.eu or linuxpackages.net (though I don't like linuxpackages.net). I have never used automated tools like this, so I don't know how good they are. I still have the opinion that, if you want dependency resolution, you should use a distro that supports it natively. I don't like dependency resolution, so I'm comfortable with Slackware. However, if you REALLY want to use Slackware AND have dependency resolution using third-party repos, slapt-get is a nice choice. There's also swaret, but I know even less about that.

I compile stuff from source all the time, so it's a very 'realistic possibility', in fact many times you have to do it because there don't exist slackware packages for everything. The environment, well that's up to you, since you're coming from Gentoo you'll want CFLAGS, I usually export those from ~/.bashrc that way most configure scripts pick them up. Newer Slackware versions come with cmake, as well as plenty of development libraries. I've never had problems compiling most programs in Slackware. If you have a problem use a Slackbuild and it will work for sure. Problems may appear when trying to compile GNOME apps that require GNOME or say they do, usually --disable-gnome helps sometimes. Lua is also problematic because the devs are lazy and don't bother with a lua.pc, this causes problems so you'll have to make your own. Other than that I can't remember too many problems compiling.

Removing Slackware packages will also leave files behind sometimes. This is done on purpose. Usually these are only config files which install under /etc. The philosophy is that if you have edited or created your own custom config file for a cretain program, uninstalling the packages should not remove the conf file. this is accomplished by naming such conf files with the '.new' suffix. When the package is installed, the included doinst.sh script wil handle the conf file in such a way as to not overwrite any existing file which you have edited. Otherwise, the file is renamed without the '.new' suffix -but in the database entry for that package, the file is listed with the '.new' suffix, so when removepkg is run, the file (without the '.new' suffix will not be removed.

You can see how this works by eaxmining nearly any package which installs a config file under /etc.

Just as the plural of "sheep" is "sheep", the plural of "source code" is "source code".

Is it usually considered better practice to use the '.new' option or the '.orig' option? I've been going for '.orig' so far -- only checking the diff when something doesn't seem to work. Is there some advised philosophy in this point?

If I change something from default, I'll usually copy the original to a .orig for safe keeping. Any package that installed a config file as a .orig would probably overwrite my backup copy. I'm sure I'm not the only one who will do this. Having the package install the file as a .new and then moving it into place if (and only if) there isn't an existing file is a much nicer approach.

PatV's doinst.sh scripts use the '.new' suffix. Using '.orig' is more likely to conflict with something, since that is a common way of designating original files.
My src2pkg program uses the :new suffix and will automatically write the doinst.sh for you when it finds .new files in the package -in fact it will place them there for you simply by putting them beside the sources. And, if the files are in PKG_DIR/etc/rc.d, it will also write a routine in the doinst.sh which adds an entry for the new 'service' in your rc.local file.

"moving it into place if (and only if)there isn't an existing file"
Actually it doesn't work like that. The .new file and the existing file get theri md5sums compared. If the two sums are different, then the new file doesn't get renamed. This means that if you have altered the original the new file gets saved with the .new extension intact. It also gets saved if the original file is unaltered but is different than the new one -when the conf file for a later version has changes it still won't overwrite an existing file. If there are no chnages in the new file and the old one is unaltered, the new one gets thrown away.

Thanks for the correction gnashley.

Ofcourse, if the two sums are the same, then it really doesn't matter whether it gets renamed either.

... other than that you won't end up with a useless file.new that is exactly the same as an existing one. I suppose that's worth taking the extra step for.


G.