I've been building my own Slackware packages for a while now, and up until now I've done all the builds on a Slackware 11 install dedicated to that one task.

But lately I've noticed that some of my packages have become "unclean" due to my own fault: I've slowly added several packages here and there, to accomodate various dependencies.

This is, of course, not very good in the long run.

So I was wondering: How do you keep a clean build enviroment?

F.ex. for some packages I want to have PostgreSQL installed, and for others I don't. For some I need APR, and for others I don't. The more packages I build, the harder it gets to maintain my enviroment in a clean state for each package.

I need advice!

Thomas

You could do a complete reinstall after every build, since you say you have a machine dedicated to your builds. I'm not seriously suggesting that as an option though, since it would get tiresome quickly.

I believe that you could achieve something similar with virtual machines without most of the hassle. I seem to recall reading that it is possible to "roll back" a virtual machine, or uninstall the "used" one, to reinitiate a pristine copy of the original system. Unfortunately, I don't have any experience with virtual machines just yet, so someone else will have to fill in more of the detail.

As hussar says, virtualization is definitely the way to go!

To begin with, I recommend reading Alien Bob's excellent wiki on the subject at: http://alien.slackbook.org/dokuwiki/...slackware:qemu

-y1

I thought virtualization might be the best way to go, but I've avoided it in the past because it seems to be very time consuming to get up and running.

But now, armed with a massive guide, I might give it a try. I have to do something, to avoid the "unclean" packages I'm building right now.

Thomas

so, what what's wrong with chroot?

Nothing.. Absolutely nothing.

The question should perhaps instead be: How can chroot help me solve the task at hand?


Thomas

Basically you would install all your packages with installpkg -root bla into some directory and, maybe, mount (with -o bind) /dev /proc and /sys. With 'chroot /bla' you would be in a complete isolated system to mess with.

i think however some discipline when installing software (for starters always make a package) is easier than that

You'd have to re-install your complete chroot environment when you want to build a new package, because you can never be sure that you don't keep leftovers from previous package builds/installs.

With a virtual machine manager like QEMU, or VMware if you want, it is possible to create a default virtual machine, and use that as the basis for a "snapshot" image where you build and test your package. The snapshot will be always exactly the same, everytime you boot it.

Also, with a chroot, you will always be running your own kernel with all the modules loaded for the hardware in the machine. If you want to be as clean as possible, a VM offers the advantage of a kernel that you choose, and a deterministic set of virtual hardware - usually virtualized hardware is pretty straightforward and this helps in building clean dependency-free packages IMO.

Eric

i was going to ask why there is a need to keep clean build environments, when you build a program inside its own clean directorys, but then it struck me that while compiling a program, the program checks certain parts of the system for libraries it needs etc. but then if your installing to a clean environment, wouldnt the program say 'library not found'? and cause some problem? apologies for my ignorance on this, im still very much a noob, any insight appreciated

You gotta find those errors. For example if you have imlib2 installed for some reason and try to compile idesk to show icons on your desktop you might think "wow, cool, it doesn't need any dependency" but in fact it requires imlib2 to be installed. If you just distributed your idesk Slackbuild or package the users who download or use it would run into this unmet dependency problem.

On the other hand if you use a clean build environment and you get imlib2 and idesk to build and work there you can give the packages or Slackbuilds away and be sure that it should work on every box with the same Slackware version.

I hope that answers your question

I usually run a GTK-1.2 only system but sometimes compile stuff for GTK-2. I just uninstall the GTK-2 and usually pkgconfig packages to be able to compile 'clean' GTK-1.2 stuff(cairo, atk, etc don't get used or detected if GTK-2 is not present. Same for GNOME or KDE/QT packages, I just remove the toolkit packages which are not supposed to be in there before building. For KDE or QT stuff it's really much easier as there are less packages.
Using slapdeptrack or some other means of listing the dependencies of each program will help you to dtermine what you need to remove.

yes, thankyou