librelist archives

« back to archive

question about homebrew avoiding dependencies duplication

question about homebrew avoiding dependencies duplication

From:
francesco tartaggia
Date:
2010-01-24 @ 16:17
Hi,
I've been reading homebrew's page on GitHub and got concerned about
section 9 in README.md ("No duplication").
I'm not a mac user yet (I'm considering to switch soon, but I need to
check out various dev tools) and used MacPorts just once so I can't
really compare the two package managers. So, when you say "Homebrew
uses what is already there" you mean that you do not duplicate
dependencies that already ship with Mac OS X distribution? If
so,consider the following scenario:
- library X.Y-version1 is included in Mac OS X
- I install product A (which depends on X.Y-version1) using homebrew
- Apple upgrades X.Y to version2 breaking compatibility with version1.

Since homebrew did not duplicate X.Y-version1, now product A is
missing one of its dependencies, right? Can I ask homebrew to check
and report broken dependencies?

Thanks a lot for your help!
Yours sincerely,
Francesco Tartaggia

Re: [homebrew] question about homebrew avoiding dependencies duplication

From:
Mike Arthur
Date:
2010-01-24 @ 21:52
On 24 Jan 2010, at 16:17, francesco tartaggia wrote:

> - library X.Y-version1 is included in Mac OS X
> - I install product A (which depends on X.Y-version1) using homebrew
> - Apple upgrades X.Y to version2 breaking compatibility with version1.

Apple don't do this unless you are doing major version OS jumps (e.g. 
10.5->10.6) and even then, if you have the SDKs for older versions, they 
will still be around (they are possibly around even without the SDKs, I'm 
not sure). Regardless, your argument applies to any piece of software 
distributed on OSX, not just Homebrew.

If this still concerns you, might I suggest checking out Fink and/or 
Macports which do duplicate all the libraries (completely unnecessarily in
my opinion).

--
Cheers,
Mike Arthur
http://mikearthur.co.uk

Re: [homebrew] question about homebrew avoiding dependencies duplication

From:
Max Howell
Date:
2010-01-24 @ 22:00
Indeed, Apple are committed to binary compatibility forever. Though
there is a history of some breakage, in general there is nothing to
worry about.

Generally speaking individual products, eg. libxml, maintain binary
compatibility rigorously as dictated by the POSIX specification. So
there is a double helping of reassurance.

If you still feel nervous, indeed, products like MacPorts offer a
complete autarky to depend on. If you trust them of course.

>> - library X.Y-version1 is included in Mac OS X
>> - I install product A (which depends on X.Y-version1) using homebrew
>> - Apple upgrades X.Y to version2 breaking compatibility with version1.
>
> Apple don't do this unless you are doing major version OS jumps (e.g. 
10.5->10.6) and even then, if you have the SDKs for older versions, they 
will still be around (they are possibly around even without the SDKs, I'm 
not sure). Regardless, your argument applies to any piece of software 
distributed on OSX, not just Homebrew.
>
> If this still concerns you, might I suggest checking out Fink and/or 
Macports which do duplicate all the libraries (completely unnecessarily in
my opinion).

Re: [homebrew] question about homebrew avoiding dependencies duplication

From:
francesco tartaggia
Date:
2010-01-24 @ 23:08
Thanks a lot for your replies! I don't feel nervous at all, I was just
curious about the issue.

Is POSIX really about binary compatibility? I thought it was only
about API source code compatibility.

Thank you again for your help.
FT

On Sun, Jan 24, 2010 at 11:00 PM, Max Howell <max@methylblue.com> wrote:
> Indeed, Apple are committed to binary compatibility forever. Though
> there is a history of some breakage, in general there is nothing to
> worry about.
>
> Generally speaking individual products, eg. libxml, maintain binary
> compatibility rigorously as dictated by the POSIX specification. So
> there is a double helping of reassurance.
>
> If you still feel nervous, indeed, products like MacPorts offer a
> complete autarky to depend on. If you trust them of course.
>
>>> - library X.Y-version1 is included in Mac OS X
>>> - I install product A (which depends on X.Y-version1) using homebrew
>>> - Apple upgrades X.Y to version2 breaking compatibility with version1.
>>
>> Apple don't do this unless you are doing major version OS jumps (e.g. 
10.5->10.6) and even then, if you have the SDKs for older versions, they 
will still be around (they are possibly around even without the SDKs, I'm 
not sure). Regardless, your argument applies to any piece of software 
distributed on OSX, not just Homebrew.
>>
>> If this still concerns you, might I suggest checking out Fink and/or 
Macports which do duplicate all the libraries (completely unnecessarily in
my opinion).
>

Re: [homebrew] question about homebrew avoiding dependencies duplication

From:
Max Howell
Date:
2010-01-24 @ 23:38
> Thanks a lot for your replies! I don't feel nervous at all, I was just
> curious about the issue.
>
> Is POSIX really about binary compatibility? I thought it was only
> about API source code compatibility.

Techincally you have to keep binary compatibility for dynamic
libraries based on the soname.

So libxml.2.0.1.dylib cannot break binary compat until libxml.3.0.1.dylib.

Core libraries obey this, though on Linux things are a little less
strict (though distributions would make efforts to ensure nothing
breaks). But on a system like OS X, Apple wouldn't upgrade anything
that broke it since the standard distribution mechanism for vendors is
binary and not source.

On OS X the only exception here has been that binary compat has broken
over several older GCC releases. But everything since 10.3.10 has been
compatible. And even then Apple installed both versions for software
that needed them.

Max

Re: [homebrew] question about homebrew avoiding dependencies duplication

From:
francesco tartaggia
Date:
2010-01-25 @ 08:56
Nice, thanks a lot for the explanation!
FT

On 25 Jan 2010, at 00:38, Max Howell <max@methylblue.com> wrote:

>> Thanks a lot for your replies! I don't feel nervous at all, I was  
>> just
>> curious about the issue.
>>
>> Is POSIX really about binary compatibility? I thought it was only
>> about API source code compatibility.
>
> Techincally you have to keep binary compatibility for dynamic
> libraries based on the soname.
>
> So libxml.2.0.1.dylib cannot break binary compat until libxml. 
> 3.0.1.dylib.
>
> Core libraries obey this, though on Linux things are a little less
> strict (though distributions would make efforts to ensure nothing
> breaks). But on a system like OS X, Apple wouldn't upgrade anything
> that broke it since the standard distribution mechanism for vendors is
> binary and not source.
>
> On OS X the only exception here has been that binary compat has broken
> over several older GCC releases. But everything since 10.3.10 has been
> compatible. And even then Apple installed both versions for software
> that needed them.
>
> Max