[haiku-development] Re: Package Management - devel or not to devel?
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 04 Sep 2013 10:19:22 +0200
On 2013-09-04 at 07:10:00 [+0200], John Scipione <jscipione@xxxxxxxxx> wrote:
> On Wednesday, September 4, 2013, scottmc wrote:
> >
> > The negative use case is that when you build something that optionally
> >> requires a package...
> >>
> >
> > Your negative use case doesn't apply here. If you are building something
> > and it has a specific build requirement, you simply define those in the
> > .recipe file as being required...
> >
>
> I think you missed the /optionally required/ part, AFAIK Haiku's package
> manager doesn't solve this any better than Linux distros do, if it does
> than I withdraw my complaint.
No, Scott didn't miss the /optionally required/ part. The main purpose of
haikuporter and the haikuports tree is to provide a well-defined, consistent
set of features for each port. Many ports come with optional requirements,
but the packager needs to select the active features in the recipe file,
such that the set of features of this port is locked down. Without this,
dependency hell caused by incorrect dependency declarations would be the
result. And the frustration with package management systems on Linux that
has been mentioned on this list several times is usually the result of
dependency hell.
The use case of a developer downloading a port and simply invoking configure
and make may apply to local software installations, but when the intention
is to distribute the resulting software, some more care should be taken to
avoid the automatic activation of build features just because another
software happens to be installed on the system.
Solving the inter-dependencies between ports isn't easy, and it has given
Ingo and me a *lot* of headaches during our work on PM. Please believe me
when I say that it is absolutely essential to start each port by defining
the precise set of features that will be made available to the port's build
system.
To summaryize: Drive-by-building is the root of all evil with respect to
software distribution.
Additionally, I completely fail to see why merging _devel packages into main
packages would help at all with building some other software. The main
problem would still be the same: a build system looks for mandatory and/or
optional requirements and, if some mandatory ones are missing, it will
complain.
I've mentioned this before and nobody seemed to have taken notice, so here's
an example: subversion's build system requires apr, apr_util, expat,
libiconv, libxml2, neon, sqlite and zlib.
Some of these are likely to be on your disk already (zlib, libiconv and
libxml2), but if neon happens to be missing, the build system will still
fail. All that merged devel packages would do is that they decrease the
likelihood of a missing dependency by some percentage. It's not as if they'd
actually solve anything.
cheers,
Oliver
Other related posts:
