[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:
