I've seen a lot of threads on how to build packages crop up recently and after this afternoon's upgradepkg faux-pas (one too many /*s and now a broken glibc) it got me thinking.

Package building: where and on what?

* Are packages built on a clean-installed system? (that is to say: full install from disk)

* Theoretically could I build a 10.2 package with a 10.0 compiler? (I mean using 10.0 d/ with 10.2 l/ ... now i think about it, it sounds like a bad idea)

* After searching, I found Alien Bob uses QEMU for package building: do you build them incrementally on top of one another? Clearly deps must be met, but, once those deps are met is the system reverted for basically a "clean install" again?

* How important is recursion in package building? I'm familiar with boot-strapping gcc and making it build itself once glibc is done, but what about building something like a new version of something you already have installed? In my mind it sounds like a "tainted" method, but logic dictates that (except glibc, perhaps) a library cannot depend on itself for compilation and therefore building a package (effectively) over the top of itself is not going to break anything.

* Anything else you suspect is pertinant to this situation is welcome!

- Piete.

Yes, I have a full install of Slackware 10.2 in a QEMU virtual machine. When I want to compile a package, I start an instance of this Slackware 10.2 - in what you basically can call "snapshot mode" of QEMU. This means that all the changes that are made to the virtual Slackware system are lost once I kill QEMU. Next time I start QEMU, I will have my pristine Slackware 10.2 back again.
This allows me to build packages that only have dependencies against original Slackware packages. When I need to build a package that depends on another non-slackware package, I will have to install that first before building my package.

An additional advantage of this procedure is that when I screw up my SlackBuild script and it erases half my Slackware disk, this will only happen in the snapshot image. After I kill and restart QEMU, I can fix my scripting error and start fresh, no harm done.

Hope that clears up things a bit.

Eric

I understand, that theoretically, that would break some C++ programs, because of the newer C++ ABI not being supported by the older complier. It's, indeed, a bad idea.

I guess that there shouldn't be many recursive things. And unless you are building from scratch, it's quite unlikely that you ever find them.

And in case that a library depends on itself (probably an older version) for building, just build in another dir and do the overwrite as atomically as possible, unless you know that nothing is using it.

ive built a whole slackware inside a chroot, and it worked until i upgraded then things started to break

Eric, theoffset and bird603568 - thankyou for your replies! I feel happy with the general consensus and figure it's time to investigate QEMU!

Many thanks again,
- Piete.

Great thread. My pkgbuild-0.9.2 currently installs to / while tracking with installwatch. I use the backup feature so that any system files which are to be overwritten are backed-up and then arbitrarily restored only a few instructions later. It's been safe through thousands of packages including cross-platform compilers.

More than once fakeroot has been suggested, but using QEMU sounds even better.

On questions of inter-version comaptiblitiy and dependency, please note that Slackware is a collection of binary packages. Nearly every version contains packages which were created under a previous version. If you ldd every executable on the system you'll get a certain, probably surprising result. If you rebuild every package from the given sources and scripts all at the same time, and then ldd all the binaries, you'll find a different result.
Just having the list of packages won't let you duplicate your system, since the compile order most certainly affects dependency specifics. There are several key programs and libraries which do have 'circular dependencies' and must be compiled more than once, at specific points.

In general programs have better backward compatibility than libraries have forward compatibility.

I have QEMU running with Slackware installed as the Guest OS. What's the best way to share files between the guest and host? For example, I'd like to be able to move source files from the host to the guest... and move packages or SlackBuild files from the guest to the host.

Is it possible to mount an existing partition on the hard drive? Can I use a USB drive as an intermediary?

I'm probably missing something obvious... just a nudge in the right direction would be helpful.

There are many ways to share files between host (the OS where you run QEMU) and the guest (the OS that runs "inside" QEMU).

* You can export part of your host's filesystem through NFS
* You can setup Samba shares on the host
* You can transfer files between host and guest using rsync or scp, or use fuse/sshfs to mount part of the host filesystem in the guest using a ssh account
* You can use the commandline parameter "-hdb fat:/some/directory/on/the/host" to make part of the host filesystem available to the guest as a FAT disk partition

All but the last can also be applied with "host" and "guest" switched of course.

Eric

Thank you for pointing me in the right direction.

Now I just have to remember that I can only do stupid stuff when I'm in QEMU.