On Fri, 2005-12-30 at 22:54 +0900, Jason Stubbs wrote:
>
>
> A still inelegant solution, but one that I could live with, is to
> leave SLOT handling as it is now and to take Brian's syntax of
> key:slot,slot using it specifically for the case where a set of
> ebuilds must all use the same slot.
On Friday 30 December 2005 22:13, Spider (DmD Lj) wrote:
> it would block against "requirement of same package with different SLOT.
>
> However, since the ~ atoms are explicit and separate ( this depend tree
> could as well be called :
> app-text/docbook-sgml-dtd:3.0
> app-text/docbook-sgml-dtd:3.1
On Fri, 2005-12-30 at 21:49 +0900, Jason Stubbs wrote:
> On Friday 30 December 2005 21:17, Spider (DmD Lj) wrote:
> >
> > No, what you suggested was that for the case of when you depend on a
> > SLOT, then the tree is flattened. My point was for the generic case :
> >
> > DEPEND=">=kde-base/kdeli
On Friday 30 December 2005 21:17, Spider (DmD Lj) wrote:
> On Fri, 2005-12-30 at 10:35 +0900, Jason Stubbs wrote:
> > On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote:
> > > On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote:
> > > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[
On Fri, 2005-12-30 at 10:35 +0900, Jason Stubbs wrote:
> On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote:
> > On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote:
> > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
> > >
> > Thats actually viable. For -installe
On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote:
> On Tue, 2005-12-27 at 19:06 +, Ciaran McCreesh wrote:
> > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
> >
> > wrote:
> > | On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote:
> > | > Nnnope. If you modify
On Wednesday 28 December 2005 16:42, Ciaran McCreesh wrote:
> On Wed, 28 Dec 2005 16:36:28 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
>
> wrote:
> | The problem is caused by packages being dependencies from multiple
> | sides. The trick is that if a package is pulled in by one side it
> | should be t
On Wed, 28 Dec 2005 16:36:28 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| The problem is caused by packages being dependencies from multiple
| sides. The trick is that if a package is pulled in by one side it
| should be taken for granted by the other side if it satisfies it's
| dependencies.
On Tuesday 27 December 2005 18:37, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 18:07, Ciaran McCreesh wrote:
> > It's worse than O(n^n) if you try to do USE dep conflict resolution
> > too...
>
> Theoretically yes, practically the worst number of dependency levels we
> speak of to walk up/d
On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote:
| > Nnnope. If you modify an eclass it forces a cache regen for packages
| > using said eclass (except possibly if you're using an overlay, but
| > that's a separ
On Tue, 27 Dec 2005 19:27:01 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| - We speak about ebuilds, which are installed and need to be
| reinstalled. There is no version cycling (or I do not get what you're
| after, please explain in that case).
foo-1.0: DEPEND="=foo-2.0"
foo-2.0: DEPEND=""
f
On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote:
> Nnnope. If you modify an eclass it forces a cache regen for packages
> using said eclass (except possibly if you're using an overlay, but
> that's a separate issue...).
You're trying to solve something which is already solved, but this ha
On Tuesday 27 December 2005 18:44, Ciaran McCreesh wrote:
> Can you prove it, for the "allow USE and version cycling" case? (Hint:
O.k, let m treat you as a the hot potato that you're Ciaran:
- We speak about ebuilds, which are installed and need to be reinstalled.
There is no version cycling (o
On Tue, 27 Dec 2005 18:44:01 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| On Tuesday 27 December 2005 18:10, Ciaran McCreesh wrote:
| > eclass, and no -r bump.
|
| Then it would not be possible to build the Application against
| different KDE versions and those who want to stay with a previou
On Tue, 27 Dec 2005 18:37:05 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| On Tuesday 27 December 2005 18:07, Ciaran McCreesh wrote:
| > It's worse than O(n^n) if you try to do USE dep conflict resolution
| > too...
|
| Theoretically yes, practically the worst number of dependency levels
| we
On Tuesday 27 December 2005 18:10, Ciaran McCreesh wrote:
> eclass, and no -r bump.
Then it would not be possible to build the Application against different KDE
versions and those who want to stay with a previous KDE version wouldn't be
able to install any application. And conditional dependenci
On Tuesday 27 December 2005 18:07, Ciaran McCreesh wrote:
> It's worse than O(n^n) if you try to do USE dep conflict resolution
> too...
Theoretically yes, practically the worst number of dependency levels we speak
of to walk up/down is not infinite ;). Of course there's no chance to get
this li
On Tue, 27 Dec 2005 14:05:21 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| On Tuesday 27 December 2005 04:08, Brian Harring wrote:
| > So note the comment in the email you are responding to about locking
| > down the used dep/rdeps for an install.
|
| That would be a maintenance nightmare. Eve
On Tue, 27 Dec 2005 16:48:55 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| Well, it shouldn't be unsolvable. Choosing can be done with the
| following process:
Your algorithm doesn't work for cases which can be solved by up / down
cycling of a version. It also doesn't work for cases where we n
On Wed, 28 Dec 2005 01:20:50 +0900 Jason Stubbs <[EMAIL PROTECTED]>
wrote:
| If backtracking was all there was to it, it could be done very
| quickly of course. However, it's essentially a brute force method;
| I'm not very good with O notation but I think it's O(n^n). I've got
| an algorithm in my
> On Monday 26 December 2005 21:28, Ciaran McCreesh wrote:
> > On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
> > Well, any library that changes ABI should use a different SLOT for each
> > revision. So SLOT depends should be able to replace the need for = and
> > ~ and < and
On Tuesday 27 December 2005 17:06, Jason Stubbs wrote:
> >
> > What about using the "&& ( kde-libs/kde:4 >=kde-libs/kde-4.0.1 )" syntax,
> > where the && would indicate that the atoms are to be folded, and consider
> > a single package that should satisfy them instead of the default where it
> > wo
On Saturday 24 December 2005 04:40, Jason Stubbs wrote:
>
> > I don't think its trolling when we've been let down on it in the past,
> > had it postponed to "the great redesign" ( project baghira, I think,
> > too) And so on.
>
> "Even though I'd probably not hold my breath"? It's something tha
On Tuesday 27 December 2005 01:33, Carsten Lohrke wrote:
> On Monday 26 December 2005 21:28, Ciaran McCreesh wrote:
> > If they're purely in DEPEND, that one isn't even an incompatability.
>
> Right. But it's not that unlikely to see such a corner case sooner or later
> and it would be good if Port
On Monday 26 December 2005 21:28, Ciaran McCreesh wrote:
> On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
> Well, any library that changes ABI should use a different SLOT for each
> revision. So SLOT depends should be able to replace the need for = and
> ~ and < and <= depend
On Saturday 24 December 2005 04:50, Jason Stubbs wrote:
> On Saturday 24 December 2005 10:25, Ciaran McCreesh wrote:
> > On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <[EMAIL PROTECTED]>
> >
> > wrote:
> > | kde-libs/kde:3
> > | ^^^ need any kde, with slotting enabled.
> > |
> > | kde-libs/kde:3
On Tuesday 27 December 2005 14:59, Jason Stubbs wrote:
> Do you mind reading and replying to the second paragraph (which happens to
> be the only new information I brought to this thread). Underlining words to
> emphasize a point to me that I've opened by agreeing is really not
> necessary.
I did
On Tuesday 27 December 2005 22:45, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 14:00, Jason Stubbs wrote:
> > If all three of those packages were first built against kdelibs:3.4 and
> > then kdelibs:3.5 became available then rebuilding any one of them without
> > rebuilding the others will
On Tuesday 27 December 2005 14:00, Jason Stubbs wrote:
> If all three of those packages were first built against kdelibs:3.4 and
> then kdelibs:3.5 became available then rebuilding any one of them without
> rebuilding the others will break digikam. I can't see how it's directly
> represented in the
On Tuesday 27 December 2005 04:07, Ciaran McCreesh wrote:
> But it's not binary compatible between KDE slots. So, once we
> have :slot dependencies, you should link to a specific :slot (possibly
> controlled via USE). It's like packages that can use either gtk or gtk2
> -- this has to be handled vi
On Tuesday 27 December 2005 04:08, Brian Harring wrote:
> So note the comment in the email you are responding to about locking
> down the used dep/rdeps for an install.
That would be a maintenance nightmare. Every time a new KDE versions comes out
a new ebuild revision for every package depending
On Tuesday 27 December 2005 12:08, Brian Harring wrote:
> On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote:
> > On Tuesday 27 December 2005 03:40, Brian Harring wrote:
> > > The version of digikam being merged requires slot=3.5- it should be
> > > depending on libk* slot=3.5, also, no
On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 03:40, Brian Harring wrote:
> > The version of digikam being merged requires slot=3.5- it should be
> > depending on libk* slot=3.5, also, no?
>
> No! It (and also its dependencies) can be built against e
On Tue, 27 Dec 2005 03:54:38 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| On Tuesday 27 December 2005 03:40, Brian Harring wrote:
| > The version of digikam being merged requires slot=3.5- it should be
| > depending on libk* slot=3.5, also, no?
|
| No! It (and also its dependencies) can be bu
On Tuesday 27 December 2005 03:40, Brian Harring wrote:
> The version of digikam being merged requires slot=3.5- it should be
> depending on libk* slot=3.5, also, no?
No! It (and also its dependencies) can be built against each 3.x slot.
> As long as the information is represented dependency wise
On Tue, Dec 27, 2005 at 03:36:00AM +0100, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 03:11, Brian Harring wrote:
> > Never said anything about 2.1 + resolver enhancements (no clue where
> > that one came from). Merely commenting on your raised issues about
> > use/slot deps.
>
> From you
On Tue, Dec 27, 2005 at 03:32:04AM +0100, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 03:11, Brian Harring wrote:
> > Either way, still not totally following your complaint, thus an actual
> > example would help (easiest to assume I'm a moron, and start at that
> > level of explanation).
>
On Tuesday 27 December 2005 03:11, Brian Harring wrote:
> Never said anything about 2.1 + resolver enhancements (no clue where
> that one came from). Merely commenting on your raised issues about
> use/slot deps.
From your words. Thanks for destroying my hope in two sentences. ;p
So we add this d
On Tuesday 27 December 2005 03:11, Brian Harring wrote:
> Either way, still not totally following your complaint, thus an actual
> example would help (easiest to assume I'm a moron, and start at that
> level of explanation).
O.k.
1. You have KDE 3.4 and Digikam (version doesn't matter) installed
On Tue, Dec 27, 2005 at 03:07:52AM +0100, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 02:23, Ciaran McCreesh wrote:
> > Nooo! That's exactly the point I was making. Carsten is assuming that
> > by using [slot:bar] syntax, no backwards incompatibility will be
> > introduced by adding a new [
On Tuesday 27 December 2005 02:42, Brian Harring wrote:
> Well, we all seem to be missing the issue, so please spell it out
> clearly (rather then "it's going to get bad"). Didn't grok it from
> the previous email, so spell it out please :)
Just did so in the answer on your other email.
Carsten
On Tue, Dec 27, 2005 at 03:01:13AM +0100, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 02:29, Brian Harring wrote:
> > So... basically, your concern is with the resolver, not use/slot deps
> > syntax.
>
> I did not say that this would have anything to do with the syntax. Am I right
> to ex
On Tuesday 27 December 2005 02:23, Ciaran McCreesh wrote:
> Nooo! That's exactly the point I was making. Carsten is assuming that
> by using [slot:bar] syntax, no backwards incompatibility will be
> introduced by adding a new [fish:] key.
Nooo! ;) I said it would look more consistent, than always
On Tuesday 27 December 2005 02:29, Brian Harring wrote:
> So... basically, your concern is with the resolver, not use/slot deps
> syntax.
I did not say that this would have anything to do with the syntax. Am I right
to extract from your words that we get rid of ~arch users complains about
up/do
On Tue, Dec 27, 2005 at 02:31:02AM +0100, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote:
> > You solve this either by SLOTting bar and making each bar SLOT use a
> > SLOT dep upon KDE, or by using USE flags and [use]:slot deps.
>
> It's not a that uncommon case a
On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote:
> You solve this either by SLOTting bar and making each bar SLOT use a
> SLOT dep upon KDE, or by using USE flags and [use]:slot deps.
It's not a that uncommon case and would lead to dozens, very likely (depending
on the future development
On Mon, Dec 26, 2005 at 09:09:31PM +0100, Carsten Lohrke wrote:
> On Saturday 24 December 2005 02:04, Brian Harring wrote:
> > dev-lang/python[tcltk]
> > ^^^ need that atom resolved with use flag tcltk enabled
>
> I think that's exactly what someone told me months ago. :)
>
> > >=sys-apps/portage
On Mon, 26 Dec 2005 17:17:54 -0800 Brian Harring <[EMAIL PROTECTED]>
wrote:
| On Tue, Dec 27, 2005 at 01:03:49AM +, Ciaran McCreesh wrote:
| > On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring
| > <[EMAIL PROTECTED]> wrote:
| > | Not saying it's a great idea, but EAPI exists to provide
| > | imm
On Tue, Dec 27, 2005 at 01:03:49AM +, Ciaran McCreesh wrote:
> On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <[EMAIL PROTECTED]>
> wrote:
> | Not saying it's a great idea, but EAPI exists to provide immediate
> | transition to incompatible changes instead of the usual "work out a
> | semi
On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <[EMAIL PROTECTED]>
wrote:
| Not saying it's a great idea, but EAPI exists to provide immediate
| transition to incompatible changes instead of the usual "work out a
| semi backwards compatible way, don't use it for 6 months, then deal
| with the
On Tue, Dec 27, 2005 at 12:46:49AM +, Ciaran McCreesh wrote:
> | > The existing syntax is just as extensible. Up the EABI revision, and
> | > start adding new syntax as needed.
> |
> | EAPI has nothing to do with the consistency of the syntax. Getting it
> | once right, is what you usually cal
On Tue, 27 Dec 2005 01:33:13 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| The problem is not the SLOT change, but to build "foo" depending on
| "bar" against KDE X, while bar is built against KDE Y. "foo" and
| "bar" support all slotted KDE versions, but they need to be build
| against the sam
On Monday 26 December 2005 21:28, Ciaran McCreesh wrote:
> If they're purely in DEPEND, that one isn't even an incompatability.
Right. But it's not that unlikely to see such a corner case sooner or later
and it would be good if Portage catches it, instead spitting out a weird
message, leaving th
On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <[EMAIL PROTECTED]>
wrote:
| I wonder if portage deals fine with subtle dependency
| incompatibilities, when one package has foo[!bar] and another one
| foo[bar] as dependency and spits out a reasonable error message to
| apply mutual blockers.
If
On Saturday 24 December 2005 02:04, Brian Harring wrote:
> dev-lang/python[tcltk]
> ^^^ need that atom resolved with use flag tcltk enabled
I think that's exactly what someone told me months ago. :)
> >=sys-apps/portage-2.0[sandbox,!build]
>
> ^^^ need >=portage-2.0 merged with sandbox on, build
On Sunday 25 December 2005 02:33, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]>
>
> wrote:
> | It's really pretty simple- get off your butt and chip in if you want
> | it, else you're on _our_ timeline (eg, we implement it when we deem
> | it sane/rea
On Sat, Dec 24, 2005 at 05:33:06PM +, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]>
> wrote:
> | It's really pretty simple- get off your butt and chip in if you want
> | it, else you're on _our_ timeline (eg, we implement it when we deem
> | it s
On 12/24/05, Curtis Napier <[EMAIL PROTECTED]> wrote:
> Dan Meltzer wrote:
> > On 12/24/05, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> >
> >>On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]>
> >>wrote:
> >>| It's really pretty simple- get off your butt and chip in if you want
>
Dan Meltzer wrote:
On 12/24/05, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]>
wrote:
| It's really pretty simple- get off your butt and chip in if you want
| it, else you're on _our_ timeline (eg, we implement it when we deem
| i
On 12/24/05, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]>
> wrote:
> | It's really pretty simple- get off your butt and chip in if you want
> | it, else you're on _our_ timeline (eg, we implement it when we deem
> | it sane/ready
On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <[EMAIL PROTECTED]>
wrote:
| It's really pretty simple- get off your butt and chip in if you want
| it, else you're on _our_ timeline (eg, we implement it when we deem
| it sane/ready to go).
Is Portage development done to support the needs of thos
On Sat, 24 Dec 2005 17:57:30 +0900 Jason Stubbs <[EMAIL PROTECTED]>
wrote:
| Heh. Yep, that's another one. Checking with a quick script, it seems
| that there are 478 unique SLOTs and the regex [a-zA-Z0-9\._\-]*
| matches them all. Perhaps it would be worthwhile locking it down to
| those character
On Saturday 24 December 2005 12:58, Ciaran McCreesh wrote:
> On Sat, 24 Dec 2005 12:50:33 +0900 Jason Stubbs <[EMAIL PROTECTED]>
>
> wrote:
> | SLOT is currently an arbitrary string (without spaces) so general
> | matching of "*" might be useful. Of course, there's no restriction of
> | not using "
On Sat, Dec 24, 2005 at 12:40:35PM +0900, Jason Stubbs wrote:
> On Saturday 24 December 2005 05:45, Spider (DmD Lj) wrote:
> > On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote:
> > > On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> > > > On Friday 23 December 2005 19:12, Ciaran McCr
On Sat, 24 Dec 2005 12:50:33 +0900 Jason Stubbs <[EMAIL PROTECTED]>
wrote:
| SLOT is currently an arbitrary string (without spaces) so general
| matching of "*" might be useful. Of course, there's no restriction of
| not using "*" in SLOTs at the moment either...
*shrug* SLOT will have to be tight
On Saturday 24 December 2005 10:25, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <[EMAIL PROTECTED]>
>
> wrote:
> | kde-libs/kde:3
> | ^^^ need any kde, with slotting enabled.
> |
> | kde-libs/kde:3,4
> | ^^^ need any kde, slotting 3 or 4.
I'd prefer to not have this l
On Saturday 24 December 2005 05:45, Spider (DmD Lj) wrote:
> On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote:
> > On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> > > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> > > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze
On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <[EMAIL PROTECTED]>
wrote:
| kde-libs/kde:3
| ^^^ need any kde, with slotting enabled.
|
| kde-libs/kde:3,4
| ^^^ need any kde, slotting 3 or 4.
Will foo-bar/baz:3* or foo-bar/baz:3.* work?
--
Ciaran McCreesh : Gentoo Developer (I can kill you wi
On Fri, Dec 23, 2005 at 10:30:09PM +0100, Carsten Lohrke wrote:
> On Friday 23 December 2005 21:45, Spider (DmD Lj) wrote:
> > Erm.. No, I don't think he is. We've been asking / waiting for the
> > [use] syntax to appear since before you joined the project. It's been on
> > "the list" for so long
On Friday 23 December 2005 21:45, Spider (DmD Lj) wrote:
> Erm.. No, I don't think he is. We've been asking / waiting for the
> [use] syntax to appear since before you joined the project. It's been on
> "the list" for so long that many of us have given up... ; )
He - and I thought I just missed t
On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote:
> On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> > > | Do those already work then? I'd like to
On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> >
> > wrote:
> > | > That was my original thought when I started playing with it. I
> > | > switched to po
On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
>
> wrote:
> | > That was my original thought when I started playing with it. I
> | > switched to postfix to make it more consistent with the way :slot
> | > and [use] re
On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| > That was my original thought when I started playing with it. I
| > switched to postfix to make it more consistent with the way :slot
| > and [use] restrictions work. *shrug* I guess it's down to whether
| > you conside
On Saturday 24 December 2005 02:57, Paul de Vrieze wrote:
> On Friday 16 December 2005 18:54, Ciaran McCreesh wrote:
> > On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <[EMAIL PROTECTED]>
> >
> > wrote:
> > | Just one remark: What about making the syntax a bit more familiar to
> > | C++ users:
>
On Friday 16 December 2005 18:54, Ciaran McCreesh wrote:
> On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <[EMAIL PROTECTED]>
>
> wrote:
> | Just one remark: What about making the syntax a bit more familiar to
> | C++ users:
> |
> | ~ DEPENDS="gentoo-foo::foo-bar/baz-2.1"
>
> That was my origina
On Sat, Dec 17, 2005 at 09:21:45PM +, Ciaran McCreesh wrote:
> On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
> | Ciaran McCreesh wrote:
> | > Well, that depends... If you have sys-apps/foo installed from the
> | > gentoo-x86 repository, and the breakmygentoo repositor
On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
| Ciaran McCreesh wrote:
| > Well, that depends... If you have sys-apps/foo installed from the
| > gentoo-x86 repository, and the breakmygentoo repository issues a
| > news item about sys-apps/foo, should it be displayed?
|
|
Ciaran McCreesh wrote:
Well, that depends... If you have sys-apps/foo installed from the
gentoo-x86 repository, and the breakmygentoo repository issues a news
item about sys-apps/foo, should it be displayed?
Well, probably not. Off hand, perhaps portageq could provide a query that
returns som
On Sat, 17 Dec 2005 12:38:24 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
| Looking into this a little further, it seems that
| Display-If-Installed can be implemented with `portageq match /
| ` and Display-If-Keyword can be implemented with `portageq
| envvar ARCH`. That leaves Display-If-Profile
Zac Medico wrote:
Ciaran McCreesh wrote:
except that it moves it deeper down into the "how
do I determine whether this news item is relevant?" area. And the only
way to get around that would be to move even more code into Portage
than you're already proposing.
Are the currently specified Disp
On Sat, Dec 17, 2005 at 03:48:05AM +0100, Luca Barbato wrote:
> >Just one remark: What about making the syntax a bit more familiar to C++
> >users:
> >
> >~ DEPENDS="gentoo-foo::foo-bar/baz-2.1"
> >
> >Comments?
> >
>
> what about
>
> DEPENDS="gentoo-foo/foo-bar/baz-2.1"
No, screws over >1 depth
Danny van Dyk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner schrieb:
|>>The big controversy seems to be over whether repositories carry a
|>>unique identifier string (for example, in metadata/repository_id) or
|>>whether it's user-assigned. The former is clearly the more sensi
Dan Meltzer wrote:
Like I said in a previous email, 'gentoo' corresponds to 'magic-chicken' in
your news-magic-chicken.unread files. The news reader app gets the repo
identifier from the news-*.unread files and plugs that into portageq to get the
directory where the corresponding new items c
Ciaran McCreesh wrote:
On Fri, 16 Dec 2005 14:17:13 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
| > What the heck is this 'gentoo' thing, and how does it help? Shoving
| > newsdir into portageq doesn't help *at all* with multiple repository
| > support.
|
| Like I said in a previous email, 'gent
On Fri, 16 Dec 2005 14:17:13 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
| > What the heck is this 'gentoo' thing, and how does it help? Shoving
| > newsdir into portageq doesn't help *at all* with multiple repository
| > support.
|
| Like I said in a previous email, 'gentoo' corresponds to
| 'mag
On Fri, 16 Dec 2005 16:42:53 -0500 Dan Meltzer
<[EMAIL PROTECTED]> wrote:
| Why not $(portageq newsdir) ? Currently, that would return only the
| one for main tree, but if/whenever multi repo support it added, it
| could return a space delimted list. This makes it simple to manage,
| and lets the
On 12/16/05, Zac Medico <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > | Brian agreed with you that the extended dep syntax will be necessary
> > | at some point in the future. I also agree. So, knowing that glep 42
> > | doesn't require extended depset syntax, can we stop playing this g
Ciaran McCreesh wrote:
| Brian agreed with you that the extended dep syntax will be necessary
| at some point in the future. I also agree. So, knowing that glep 42
| doesn't require extended depset syntax, can we stop playing this game
| and just settle on something like newsdir="$(portageq new
Why not $(portageq newsdir) ? Currently, that would return only the
one for main tree, but if/whenever multi repo support it added, it
could return a space delimted list. This makes it simple to manage,
and lets the portage crew
a) figure out what they want to do
b) implement it while keeping thi
On Fri, 16 Dec 2005 13:18:45 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
| I get it. The Portage team asks you to extend your spec, so you turn
| it around and ask them to extend their spec. Ha ha ha. Funny
| game. :)
No no no. The Portage team asked me to extend GLEP 42 to include support
for
Ciaran McCreesh wrote:
| Local news delivery *should* still be using the user label. Unique
| repo internal labels don't matter to glep42, since the label that
| news delivery _should_ use is what the user's configuration has named
| it.
|
| Just stating it, since tagging a unique id into the
On Fri, 16 Dec 2005 04:12:08 -0800 Brian Harring <[EMAIL PROTECTED]>
wrote:
| What's needed is an extension of the portage configuration so that
| it's able to specify multiple standalone repos, slaved (overlay)
| repos chained against the standalones, package.* filters applied to
| each repo, etc
On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <[EMAIL PROTECTED]>
wrote:
| Just one remark: What about making the syntax a bit more familiar to
| C++ users:
|
| ~ DEPENDS="gentoo-foo::foo-bar/baz-2.1"
That was my original thought when I started playing with it. I switched
to postfix to make i
On Sat, 17 Dec 2005 00:19:41 +0900 Jason Stubbs <[EMAIL PROTECTED]>
wrote:
| > DEPEND=">=foo-bar/baz-2.1::ciaranmssekritrepo"
| >
| > which would add a restriction that only packages in
| > ciaranmssekritrepo would be considered. This only works if the
| > repository knows its own identifier, howev
On Friday 16 December 2005 14:57, Alec Warner wrote:
> Ciaran McCreesh wrote:
> > On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <[EMAIL PROTECTED]>
> >
> > wrote:
> > | emerge blar --repo=ciaranmssekritrepo
> > |
> > | This accomplishes the same thing, except I get to name the repo
> > | whatever
4am, pardon typos...
On Fri, Dec 16, 2005 at 03:56:30AM +, Ciaran McCreesh wrote:
> On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <[EMAIL PROTECTED]>
> wrote:
> | 2. What choices/options are on the table for this feature?
>
> The big controversy seems to be over whether repositories carry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner schrieb:
|>>The big controversy seems to be over whether repositories carry a
|>>unique identifier string (for example, in metadata/repository_id) or
|>>whether it's user-assigned. The former is clearly the more sensible
|>>option, since i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <[EMAIL PROTECTED]>
> wrote:
> | emerge blar --repo=ciaranmssekritrepo
> |
> | This accomplishes the same thing, except I get to name the repo
> | whatever I wish, and you lose th
On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <[EMAIL PROTECTED]>
wrote:
| emerge blar --repo=ciaranmssekritrepo
|
| This accomplishes the same thing, except I get to name the repo
| whatever I wish, and you lose the ability to specify repositories in
| DEPEND.
...and it stops you from being abl
1 - 100 of 104 matches
Mail list logo
