Package distribution hassles - a proposal.

John H Terpstra jht at
Thu Feb 28 11:09:03 GMT 2002

On Thu, 28 Feb 2002, Max TenEyck Woodbury wrote:

> >From this list I'll extract the configuration and dependency information
> for each distribution for inclusion on the web-page.

But how do you propose to do this? Will one single SPEC file work for all?
If not, then this is a massive effort. The biggest hit is in maintenance
and keeping a build environment up to date so that all future releases
will build correctly.

> >> Simo Sorce wrote:
> >>>
> >>> What about building a script that will build the packages on it's own
> >>> every time a new release is made? We can also think to let it run once a
> >>> day tomake daily snapshots! Maybe it can be made part of the build farm
> >>> so that the packaging gets tested too.
> >>
> >> From what little experience I've had, it doesn't work that way.
> >>
> >> You need a base-line system to do the build on. Sometimes the
> >> patch level makes a difference. I know of three ways to
> >> have that:
> >
> > Unfortunately, to build the above we need separate virgin installed
> > systems - ie: No patches or updates. In the case of Linux OS's - update
> > packages that involve the kernel, the compiler, or the glibc libraries
> > taint the RPMS so they become dependant on the updated system.
> It's even worse than that. For example, Red Hat has on a couple of occasions
> provided update packages. Those packages were built on systems where they
> had applied all their other patches. This is often necessary when they update
> a critical system library. If someone tried to upgrade such a patched system
> with a package built on a base-line (i.e. unpatched) system, they'd get
> version conflicts. On the other hand, upgrading a base-line system with a
> package built on a patched system also generates version conflicts.
> Are you sure the kernel and compiler versions are recorded? I know the
> versions of the system libraries used are recorded, but I don't remember
> seeing kernel or compiler version conflicts. However, I've only done the
> package build bit twice for samba, so I could easily have missed something.
> Does this describe the proper procedure:
> 1) Declare a version freeze -- identify what is going into a particular
>    version and what is NOT going into that version.
> 2) Basic tests on the new version -- it better compile on the development
>    system or nobody's going to get it to work.
> 3) Build a complete set of packages on the distribution system, patches and
>    all. These binaries are not necessarily for public consumption. The
>    .src.rpm is what is important.
> 4) Test the package as an upgrade to an existing system. Test that the package
>    removes itself properly. Test the package as a 'clean' installation.
>    Basically, this makes sure all the pieces are included in the package.
> 5) Build the distribution binaries on the various base-line systems. The
>    .src.rpms built in step 3 should be used to do this. Install the
>    resulting packages on the build system to make sure they really did
>    build properly.
> 6) Clean up the build systems so they can be used again.
> Step 5 is the bear!

So! Are you not a bear hunter? ;)

- John T.

John H Terpstra
Email: jht at

An argument of minds:
"Please help me to find the intellect in Intellectual Property"
"Not me, I can't find the property in it either!"

More information about the samba-technical mailing list