[haiku-development] Re: (abandoned?) OptionalPackages still awaiting rebuild or should be just drop them from alpha3?

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 02 Jun 2011 15:52:47 +0200

On 2011-06-01 at 11:55:25 [+0200], Stephan Aßmus <superstippi@xxxxxx> wrote:
> IIRC, the reason why the packages should be built on an official release
> is that those are versioned in the ELF objects (Ingo can explain it much
> better, but he already has and it should be in the archives). Should any
> binary compatibility issue arrise, we would have an easier path to
> fixing it be using ELF symbol versioning, if I am not mistaken.

The ELF symbol versioning works on a per-symbol basis. If a binary 
in-compatible change is made, a new version for the affected 
function/variable is introduced and all objects linked against the library 
afterwards will require and use the new symbol, while an object linked 
against the library before the change will require and use the older 
symbol. That should just work even for arbitrary trunk revision.

The only problem in this respect is, if a symbol version disappears, in 
which case the object will not load anymore. This can e.g. happen when it 
is decided that a binary incompatible change isn't needed after all and is 
reverted again. It can also happen when a version name is changed. E.g. in 
my signals branch I created a new kernel and libroot version named after R1 
alpha 4. If our next release is already beta 1, the version will be renamed 
and everything linked against a libroot or kernel with the old version name 
will break.

There is another kind of versioning which we introduced for providing us 
with a means to make later compatibility work-arounds possible. We added 
symbols to the glue code that contain the Haiku and ABI version. The glue 
code is linked into each shared object, so it is possible to determine 
later on under which Haiku the object had been built. In most cases ELF 
symbol versioning will be the best tool to deal with compatibility matters, 
but a new symbol version has to be introduced right when an incompatible 
change is made. If that happened accidentally and is not detected before 
the next release, the version in the glue code does still allow for runtime 
work-arounds in a later Haiku release.

We adjust the Haiku version number first thing in a release branch. Only 
packages built after that will be tagged with the release version. Packages 
built against a trunk revision will contain a different version number. 
They can still be identified as having been built against a trunk revision, 
but it is unclear whether that happened before or after a particular 
change. So it may not be possible to decide whether or not a later 
compatibility work-around needs to be applied.

Another reason for building packages only against release versions is that 
the trunk may contain temporary screw-ups. Someone may accidentally break 
binary compatibilty and fix it a few revisions later. A package built 
during that time may be subtly broken.

> My personal opinion is that just like we don't allow last minute changes
> to the code that may introduce bugs, we should not update the packages
> at all. For some unknown to me reason, this seems to be very error
> prone. with the .bep files, it should not be the case, but apparently
> there are still many possible points of failure outside the .bep
> descriptions. Most likely the problem is that the host system may be in
> any random condition and the builds of packages turn out to be different
> based on those "outside" conditions. That's why the "chroot" environment
> is so important for building packages eventually, it means the state of
> the build system is also defined versus random.
> As long as we cannot guarantee that building the same source version of
> a piece of software with the same .bep file will produce the exact same
> output package, I find the risk of introducing breakage far outweights
> the benefit of having built the packages included with an official
> release on that official release with the proper ELF symbol versioning.
> We have never needed that until now

We had two (alpha) releases so far. That "never" applies to a very short 
list. :-)

> and all those packages are open
> source and can be reproduced at will with a fix anyhow (should the need
> really arise). So I really don't understand why we even do it. It's a
> lot of work, you have to put up with the complaints, and obscure
> breakage may become known only after we release.

You've certainly got a point there. Updating the glue code version info for 
the sake of being able to apply work-arounds later is not necessary, as we 
can just build a fixed package for the next release. The other reasons for 
rebuilding -- removed/renamed ELF symbol versions or the package having 
been built under a Haiku revision that causes a potential binary 
compatibility issue -- still remain, though. Admittedly both are relatively 
unlikely (or, in the first case, unlikely to go unnoticed), so I agree that 
as long as package building is as fragile as it seems to be, it is probably 
better to avoid rebuilding just before the release.

CU, Ingo

Other related posts: