[Helidelinux-devel] Re: Helide linux

[Bennett T. <be...@ra...>]

2004-03-08T14:32:07 Hui Zhou:
> On Mon, Mar 08, 2004 at 01:30:46PM -0500, Bennett Todd wrote:
> > 	bpmbuild filename
> >=20
> > then bpmbuild would use wget to download the sources, then it'd
> > unpack them, build them, and prepare the binary package. The binary
> > package would have all the files that were populated by that "make
> > install", plus these three:
> How do you determine the files created by make install, install-log or
> with an empty prefix directory?

A bpm spec file is OGDL that provides three values:

    pkg is the package name (including the version, I don't separate
	that out as a separate value).

    url is the list of uris of the sources; plain files must already
	be present in a src/ dir, full urls will be downloaded with
	wget if they aren't already present

    build is a shell script fragment; it should unpack, patch,
	configure, compile, and install the package. The install
	should be directed into a tmp dir found by the envar
	BPM_ROOT, created but completely empty when the script
	fragment starts running.

So I determine the files by looking in $BPM_ROOT, which looks
something like /var/tmp/bpmbuild.$pid/root, after the build script
is run.

> Why you put both the spec and src files and the binary files into the
> bpm packages?

I always want to keep track of both. You can install one or the
other by using include/exclude options on the cpio extract, but I
like a default of installing both. For custom tight server installs
I'll not only omit the sources, I'll also omit the docs. But on
normal systems I'll enjoy having everything preserved.

> IMHO, if one want to install binary, they don't need spec and src,
> and vice versa.

Splitting these out would be very easy to do, easy to automate. I
don't want it for myself.

> Why don't you distribute two sets of packages, one only with specs
> or maybe sources as well for installation from sources or just
> preparing the binary packages.

After a fashion, I do. The bpm/ dir I distribute is everything,
pre-built binaries and full sources, ready to unpack and have a full
dev environment that can bootstrap itself. The bpmdist/ dir has
snapshots at various times of the spec files, non-public sources
(i.e. sources that don't have full URLs), and (starting with the
most recent couple) the sha1 files to document what was delivered by
each package.

> The other are binary only and install with bzip2 and cpio? Am I
> right if I am lazy enough I can just obtain the binary part and
> install a system?

Yup. I believe this sequence, run from a knoppix or whatever, would
be a full system install:

- partition the drive, mkfs as needed, mount it up under e.g. /a
- wget all the *.cpio.bz2 files
- for each one, extract it under /a
- create a suitable lilo.conf, install lilo

> Rpm just includes the binary package and a spec for more versatile
> installation and configuration and dependency tracking.

rpm includes a _Lot_ more stuff. It tracks three separate values to
identify a package, the name, a separate version, and a separate
release. Then, again separate, there's an architecture, which can be
src for a source package.

> The current bpm is simpler because it uses no-custom installation
> and no-configuration and no-dependency (I haven't read your
> actual implementation yet, these are my understanding from your
> description, correct me mercilessly if I am wrong and accept my
> appology).

Dependency management hasn't been written yet, but I'm planning it
(I posted a separate note to the list about it). It won't complicate
the spec files at all, and I can still use cpio.bz2 for the package
format.

> Have you considered using rpm with extremely simple installation
> spec for the binary only distribution?

I started off planning on using rpm.

Then I discovered a few things.

(1) It's got the most completely broken, screwed up, demented i18n
    of any program I've heard of. I repackaged postfix, creating my
    own rpm. The %description in my rpm explains that my postfix
    omits Berkeley DB (exceedingly nasty license terms) and includes
    cdb (very pleasing license, and breathtakingly great
    performance). "rpm -qi postfix" doesn't show my %description, it
    shows the one for the Red Hat postfix package --- unless I set
    LC_ALL=3DC. How's _that_ for disgusting. And Red Hat states
    flat-out that this is a feature, and won't be fixed.

(2) The code is sufficiently crufty --- a decade or so of band-aid
    hacks slapped on will do that --- that it's impractical to rip
    Berkeley DB out of rpm and replace it with something with a
    civilized license.

That was enough to get me to create my own tool, and once I did I
realized it could be _So_ much simpler and still do what I need.

> > The bpm database in /var/lib/bpm/ is simple text files, not the
> What does it look like? How did you populate the data base if you only
> install with bzp2|cpio?

It's just files that are installed with bzip2|cpio. For a package
named "foo-1.0", the files would be something like

	/var/lib/bpm/foo-1.0/spec
	/var/lib/bpm/foo-1.0/src/foo-1.0.tar.gz
	/var/lib/bpm/foo-1.0/sha1

Simple text files. Once I add dependancy management, they'll be a
couple more text files alongside spec and sha1. I'll probably be
forced at some point to add {pre,post}{install,remove} scripts as
well, they'll be specified in the spec file as additional fragments
like the current build.

-Bennett