Package distribution hassles - a proposal.

[John H Terpstra]

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

>  www-106.ibm.com
>  www.gentoo.org
>  www.pingoo.org
>  linas.org
>  www.slackware.com
>  www.bestlinux.net
>  www1.rocklinux.org
>  www.debian.org
>
> >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 samba.org

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!"