| 1 |
On Tuesday 10 August 2004 21:53, Matthieu Sozeau wrote: |
| 2 |
> On Tuesday 10 August 2004 14:21, Jason Stubbs wrote: |
| 3 |
> > Hi, |
| 4 |
> > |
| 5 |
> > I couldn't really follow all that you said, but bug 39246 made a lot more |
| 6 |
> > sense. Let me see if I can summarise your requirements... |
| 7 |
> > |
| 8 |
> > For portage's role, |
| 9 |
> > * The compiler is slotted |
| 10 |
> > * The libraries are slotted against the compiler that was used to compile |
| 11 |
> > them |
| 12 |
> > * When the compiler is upgraded, all libraries are recompiled with the |
| 13 |
> > new compiler |
| 14 |
> > |
| 15 |
> > Then there is a compiler-config proggy that'll set what compiler is |
| 16 |
> > currently in use. Does that about sum it up? |
| 17 |
> |
| 18 |
> That's what i implemented yes, |
| 19 |
|
| 20 |
Which means that it'll be mishandled once portage makes use of SLOTs as the |
| 21 |
SLOTting is wrong until it is installed. |
| 22 |
|
| 23 |
> my proposal just adds more flexibility and describe a correct (i hope) |
| 24 |
> design (avoiding the use of dynamic SLOTs for the libraries, as the |
| 25 |
> 'dynamicity' would be in the hands of portage only with compiler policies). |
| 26 |
|
| 27 |
I don't understand how dynamic slots are avoided. Whether the information is |
| 28 |
in a variable named SLOT or is deduced from a combination of a package's deps |
| 29 |
and the compiler policy, I don't see a difference. Have I misunderstood |
| 30 |
something? |
| 31 |
|
| 32 |
> > If the compiler wasn't slotted, the compiler-config program wouldn't be |
| 33 |
> > necessary and the other two requirements would be easy to satisfy. If it |
| 34 |
> > is... |
| 35 |
> |
| 36 |
> We obviously have to use static SLOTs to support different compiler |
| 37 |
> versions... |
| 38 |
|
| 39 |
Well.. if the compiler wasn't slotted (or portage only had to care about the |
| 40 |
most recent version installed [which is wrong imo]) everything could be |
| 41 |
handled by simply adding a new variable to state that any reverse deps |
| 42 |
compiled against a version of this package outside of said atom must be |
| 43 |
recompiled. |
| 44 |
|
| 45 |
For example, foobar-2.3:xDEPEND="=foobar-2*". When upgrading from foobar-1.7, |
| 46 |
anything that was built with foobar-1.7 would be recompiled after foobar-2.3 |
| 47 |
was installed. |
| 48 |
|
| 49 |
> > Anyway, I'll let you confirm that these are the actual requirements |
| 50 |
> > before bouncing around ideas. |
| 51 |
> |
| 52 |
> I confirm those are the main ideas, go on ! |
| 53 |
|
| 54 |
And the major issue that covers this entire thread... |
| 55 |
|
| 56 |
emerge '~dev-lang/ocaml-3.06' |
| 57 |
emerge lablgtk |
| 58 |
emerge -u dev-lang/ocaml |
| 59 |
emerge lablgl |
| 60 |
|
| 61 |
The issue that's preventing this from happening is whether portage should also |
| 62 |
emerge lablgl against ocaml-3.06. I believe it should and I think it is a |
| 63 |
requirement for most of the people that want dynamically slotted packages. |
| 64 |
|
| 65 |
Regards, |
| 66 |
Jason Stubbs |
| 67 |
|
| 68 |
-- |
| 69 |
gentoo-dev@g.o mailing list |
Archives