No subject

Tue Dec 2 04:10:01 GMT 2003

for each distribution for inclusion on the web-page.

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


More information about the samba-technical mailing list