[haiku-development] Re: Optional Library Package
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 12 May 2010 16:13:05 +0200
On 2010-05-12 at 13:57:58 [+0200], Stephan Assmus <superstippi@xxxxxx> wrote:
> On 2010-05-11 at 23:23:46 [+0200], scott mc <scottmc2@xxxxxxxxx> wrote:
> > > Hello Folks,
> > > I was told I should probably post here. I don't have an account here,
> > > mainly
> > > because I'm not a developer.
> > > I'm following up on the article I wrote here (I'm including it to the
> > > bottom
> > > here as well).
> > > Would the Haiku team consider distributing an optional 'library only'
> > > package for Haiku?
> > > One of the most common problems when launching applications, is missing
> > > libraries. It's quite frustrating, and Haiku's forums and Haikuware are
> > > filled with comments in this regard.
> > > I'd be happy to put together a GCC2 package of libraries based on the
> > > available ones at HaikuPorts (and if that's fine with them).
> >
> > Please be patient. We (HaikuPorts) lost our previous ftp site and are
> > in the process of moving to a new place to host our binaries. Each of
> > our binary zip packages will contain an .OptionalPackageDescription
> > file so that it could potentially be used as an OptionalPackage or by
> > some future as yet unwritten Package Installation program, perhaps
> > even linked in and able to install from the Installer program in Haiku
> > someday. That's all yet TBD. But soon you'll start seeing the
> > HaikuPorts binaries come back online, which should help out in the
> > short term. If you have any requests for specific packages please
> > post a new ticket on HaikuPorts trac or on the HaikuPorts-users
> > mailing list, and we'll see what we can do.
>
> I don't think a temporary downtime of haiku-ports is the problem here. As I
> understand it, Karl wants to initiate a discussion about including more
> basic libraries in a "default installation". So the problem is not when
> haiku-ports will be back up, but for example which libraries should go into
> a default installation.
>
> On a similar note, it has not been helpful to replace system libraries
> without staying backwards compatible to the existing Haiku packages out
> there. Replacing OpenSSL and libcrypto in particular, before that the
> libpng and libjpeg updates... this could have been done while providing the
> old libraries - especially while we already had the versioning in place.
> That would have caused a lot less breakage.
We had a discussion about this a few months ago. For the libraries in the
repository Oliver introduced major API version suffixes. This doesn't really
solve the issue, since we'd still have to provide an older version of a
library when updating to a newer, incompatible one. A more radical (and
safer) approach would be to make those libraries completely private to the
system -- by suffixing them with e.g. "_haiku" and not shipping them with
headers or anything else. There would need to be separate (complete)
packages for those libraries that can be used by non-repository software.
This moves the problem to package management, but that's where it needs to
be handled anyway. Later Haiku releases can simply include compatibility
packages for earlier releases. Creating and including compatibility packages
can of course already be done without package management.
> I don't remember if we ever discussed a policy for upgrading system libs
> without maintaining compatibility with existing packages. libpng in
> particular was available as a system lib on BeOS R5, so changing that
> definitely meant breaking stuff, unless I am missing something. It
> definitely caused a lot of extra work, but I don't have an opinion on this,
> just pointing it out as something we could discuss.
You're mistaken. There's no libpng.so on the BeOS R5 CD (at least not on
mine).
Anway, I don't think that's what Karl was referring to. I think this is
about software packages that require libraries not included with Haiku.
Which admittedly is very inconvenient for users. Package management would
solve that problem.
CU, Ingo
Other related posts:
