librelist archives

Re: [homebrew] Keg-only upgrade issues

From:

Mike McQuaid

Date:

2010-09-13 @ 11:27

On 13 Sep 2010, at 12:19, Max Howell wrote:

> Please refer to the previous mail.
> 
> Keg-only sucks, but seemed like a necessary solution for a thornier
> problem, that is, some packages create conflicts and or worse problems
> when you install them in parallel to stuff that comes with OS X.
> 
> The problem discussed previously with upgrades persists with keg-only
> because there is no symlinked location that we can link dependencies
> against.
> 
> One solution is to symlink keg-only formula into a sub-prefix.
> Something like /usr/local/opt (which is in fact a valid POSIX
> directory).
> 
> So you'd get:
> 
> /usr/local/opt/icu4c/bin
> /usr/local/opt/icu4c/lib
> etc.
> 
> However, I can't be the only one who hates bolting on complexity like
> this. Issues like this are why I avoided making an upgrade command for
> so long.

A solution I thought of before, possibly just for keg-only stuff would be 
to have library symlinks like so:
/usr/local/Cellar/libfoo/1/ -> /usr/local/Cellar/libfoo/1.2.3/
/usr/local/Cellar/libfoo/1.2/ -> /usr/local/Cellar/libfoo/1.2.3/

In this case we can actually link in a way that is sensible to the 
specific library. By default this would probably involve linking to major 
versions as we'd want these changes to break.

--
Cheers,
Mike McQuaid
http://mikemcquaid.com

> A solution I thought of before, possibly just for keg-only stuff would 
be to have library symlinks like so:
> /usr/local/Cellar/libfoo/1/ -> /usr/local/Cellar/libfoo/1.2.3/
> /usr/local/Cellar/libfoo/1.2/ -> /usr/local/Cellar/libfoo/1.2.3/
>
> In this case we can actually link in a way that is sensible to the 
specific library. By default this would probably involve linking to major 
versions as we'd want these changes to break.

Currently you can `ls Cellar/foo` and see how many of foo you have
installed. Principles like this are a foundation of the platform and
as such shouldn't be messed with.

However we should be thinking about major versioning stuff. Or
whatever, I was amazed how little thought we gave this and it hasn't
mattered much.

Really the easiest way to do this is just to make eg. libfoo install
both libfoo.1 and libfoo.2.

Could we do that for Python 2.x and 3.x? It would make life easier I bet.

On 13 Sep 2010, at 12:36, Max Howell wrote:

> Currently you can `ls Cellar/foo` and see how many of foo you have
> installed. Principles like this are a foundation of the platform and
> as such shouldn't be messed with.

Fair enough. With that in mind, how about doing something like these:
/usr/local/Cellar/libfoo/.1/ -> /usr/local/Cellar/libfoo/1.2.3/
/usr/local/Cellar/.Versions/libfoo/1/ -> /usr/local/Cellar/libfoo/1.2.3/
/usr/local/.Versions/libfoo/1/ -> /usr/local/Cellar/libfoo/1.2.3/

This might be slightly abusing the "." but it might work alright?

> However we should be thinking about major versioning stuff. Or
> whatever, I was amazed how little thought we gave this and it hasn't
> mattered much.
> 
> Really the easiest way to do this is just to make eg. libfoo install
> both libfoo.1 and libfoo.2.
> 
> Could we do that for Python 2.x and 3.x? It would make life easier I bet.

Sounds like a nice approach, as long as you can still use libfoo which 
will install the default.

--
Cheers,
Mike McQuaid
http://mikemcquaid.com

"""Really the easiest way to do this is just to make eg. libfoo install
both libfoo.1 and libfoo.2.

Could we do that for Python 2.x and 3.x? It would make life easier I bet."""

*Really* don't want "brew install Python" to build both 2.7 and 3.1.2,
so perhaps that was a bad example to use here.

Yeah I figured nobody would really want that particular example.
Libraries only then. If that at all.

However I bet it would make library easier for us! ;)

> """Really the easiest way to do this is just to make eg. libfoo install
> both libfoo.1 and libfoo.2.

On 13 Sep 2010, at 17:16, Adam Vandenberg wrote:

> """Really the easiest way to do this is just to make eg. libfoo install
> both libfoo.1 and libfoo.2.
> 
> Could we do that for Python 2.x and 3.x? It would make life easier I bet."""
> 
> *Really* don't want "brew install Python" to build both 2.7 and 3.1.2,
> so perhaps that was a bad example to use here.

I don't think it should build both, just the "default" (however the hell 
we set that).

--
Cheers,
Mike McQuaid
http://mikemcquaid.com