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

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 01 Jun 2011 11:55:25 +0200

On 31.05.2011 22:33, scottmc wrote:
I've updated the wiki page, marked BeZilla and the soundfonts to "use
as is" status.  I'll try making a .bep for friss soon.  Several others
were probably built using R1/Development, so they may or may not need
to be updated?  If you know and can edit the wiki, please mark them as
ok, or not...
BeHappy and NetSurf have a few open trac tickets, basically saying
they are broken.  It's been awhile since I used OpenSound, anyone
tried it since the recent IO-APIC fixes?  I wonder if the long startup
delay is still there?

It is not necessary at all to update all of these packages. Only packages that have not 
been built on an official release "should" be updated.

Would that refer to r1a1, r1a2 and/or r1a3, or anything since r1a1,
including r1/development?  I've marked those are "may need rebuild on
a release"

Only r1a1 and r1a2 are official releases. If I had meant a random nightly, we wouldn't have to rebuilt anything, no? ;-)

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.

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

Best regards,
-Stephan

Other related posts: