Re: [gentoo-dev] Multiple Repo Support

[Spider (DmD Lj)]

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 -installed- ebuilds,  we simply unpack all
  RDEPEND logic, remove all use flags ( stored, but the use logic is
  removed from the RDEPEND since its already resolved, doesn't need to be
  there. The binary is static already )
 
  Then check vs. the installed SLOT of all RDEPEND packages, and lock our
  current deptree to the package of that SLOT...
 
 I suggested this last Tuesday.. 

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/kdelibs-3.0   (as many ebuilds look today)  

is then expanded to the current matching SLOT of kdelibs, so even if
there -wasn't- a SLOT requirement beforehand, there is one afterwards.
 
  I can smell sooo much breakage from this solution. Even though it could
  work  : )
 
 I'm not sure to interpret this as yet another snide remark or not so I'll 
 give you the benefit of the doubt and assume you're referring to sets of 
 ebuilds that require several slots. Before implementing the above, the tree 
 will be checked for any cases where the above idea will fail.


And, I know you're bitter and tangy about uncalled for remarks about
portage development, however, by looking at my assumption of suddenly
starting to tie packages to SLOT's,  yes, I predict massive levels of
interesting bugs to start appear, where we get obscure depend-cases of
things suddenly causing a rebuild of packages deep inside the tree,
which then suddenly spark rebuilds against others in the tree upwards,
due to depend atoms flicking the SLOT of one of the bottom libs that are
depended upon.


Since I also suggested (or tried to convey) the requirement that for a
single depgraph ( the graph to package foo)  there may never be SLOT
collisions for a single lib...  So  the whole mapped out tree may not,
never, contain both =kde-base/kdelibs-3:3.1 and
=kde-base/kdelibs-3:3.4 . 


As its the only viable means I see of solving such dependencies,  it
also seems to be quite prone of breakage. To simply lock down SLOT
depends would propbably not cause as much problems, however.

//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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 [EMAIL PROTECTED]
  
   Thats actually viable. For -installed- ebuilds,  we simply unpack all
   RDEPEND logic, remove all use flags ( stored, but the use logic is
   removed from the RDEPEND since its already resolved, doesn't need to be
   there. The binary is static already )
  
   Then check vs. the installed SLOT of all RDEPEND packages, and lock our
   current deptree to the package of that SLOT...
 
  I suggested this last Tuesday..

 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/kdelibs-3.0   (as many ebuilds look today)

 is then expanded to the current matching SLOT of kdelibs, so even if
 there -wasn't- a SLOT requirement beforehand, there is one afterwards.

Okay, I misinterpreted. Anyway, it looks like neither of our ideas will work:

app-text/docbook-sgml/docbook-sgml-1.0.ebuild:

RDEPEND=app-text/sgml-common app-text/openjade
=app-text/docbook-dsssl-stylesheets-1.64
=app-text/docbook-sgml-utils-0.6.6
~app-text/docbook-sgml-dtd-3.0
~app-text/docbook-sgml-dtd-3.1
~app-text/docbook-sgml-dtd-4.0
~app-text/docbook-sgml-dtd-4.1

docbook-sgml-dtd-3.0-r3.ebuild:SLOT=3.0
docbook-sgml-dtd-3.1-r3.ebuild:SLOT=3.1
docbook-sgml-dtd-4.0-r3.ebuild:SLOT=4.0
docbook-sgml-dtd-4.1-r3.ebuild:SLOT=4.1

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Spider (DmD Lj)]

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/kdelibs-3.0   (as many ebuilds look today)
 
  is then expanded to the current matching SLOT of kdelibs, so even if
  there -wasn't- a SLOT requirement beforehand, there is one afterwards.
 
 Okay, I misinterpreted. Anyway, it looks like neither of our ideas will work:
 
 app-text/docbook-sgml/docbook-sgml-1.0.ebuild:
 
 RDEPEND=app-text/sgml-common app-text/openjade
 =app-text/docbook-dsssl-stylesheets-1.64
 =app-text/docbook-sgml-utils-0.6.6
 ~app-text/docbook-sgml-dtd-3.0
 ~app-text/docbook-sgml-dtd-3.1
 ~app-text/docbook-sgml-dtd-4.0
 ~app-text/docbook-sgml-dtd-4.1

 docbook-sgml-dtd-3.0-r3.ebuild:SLOT=3.0
 docbook-sgml-dtd-3.1-r3.ebuild:SLOT=3.1
 docbook-sgml-dtd-4.0-r3.ebuild:SLOT=4.0
 docbook-sgml-dtd-4.1-r3.ebuild:SLOT=4.1
 



Hmm, however theese are the ~ atoms, I'm not quite sure how those are
treated in the current tree, however in my proposal 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
app-text/docbook-sgml-dtd:4.0
app-text/docbook-sgml-dtd:4.1

Which, for some reason, should be supported : )   

Either by casing out appearances where multiple SLOTs are depended on by
-one- package, or by saying that ~ is special-cased due to its stricter
limitations, which would make it pass by the SLOT check.   

( no, its not an elegant solution, but it might work ;)


//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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
 app-text/docbook-sgml-dtd:4.0
 app-text/docbook-sgml-dtd:4.1

 Which, for some reason, should be supported : )

 Either by casing out appearances where multiple SLOTs are depended on by
 -one- package, or by saying that ~ is special-cased due to its stricter
 limitations, which would make it pass by the SLOT check.

 ( no, its not an elegant solution, but it might work ;)

Inelegant solutions gets us no further than where we are now. ;)

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. 

Hence, rather than digikam and friends having || ( kdelibs:3.4 kdelibs:3.5 ) 
each would have just kdelibs:3.4,3.5. It still sounds messy given the 
current redesign of atom handling, but it would seem to offer a better chance 
of not being bug-ridden...

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Spider (DmD Lj)]

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. 
 
 Hence, rather than digikam and friends having || ( kdelibs:3.4
 kdelibs:3.5 ) each would have just kdelibs:3.4,3.5. It still sounds
 messy given the current redesign of atom handling, but it would seem
 to offer a better chance of not being bug-ridden... 


Hmm..  Do you mean this -after- expansion, or as hard-coded into the
tree of ebuilds?  If so, it's probably a no-go.  Since the dep as stated
in the tree doesn't even -want- to bind itself to a SLOT (can work with
any 3.x version,  is probably the most common criteria).


And, I'm not sure just how this mangling would look when expanded in the
installed package database, can you elaborate a bit?

//Spider
-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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 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
  | has nothing to do with our problem. The question is not listen the
  | possible valid KDE versions or a change of the eclass, but the need
  | to know actual used KDE version. You'd need to call e.g. kde-config
  | to get it. And this breaks caching.
 
  So you RDEPEND upon the version of KDE against which you were built,
  and use the || ( ) flattening feature that's already been proposed.

 Thats actually viable. For -installed- ebuilds,  we simply unpack all
 RDEPEND logic, remove all use flags ( stored, but the use logic is
 removed from the RDEPEND since its already resolved, doesn't need to be
 there. The binary is static already )

 Then check vs. the installed SLOT of all RDEPEND packages, and lock our
 current deptree to the package of that SLOT...

I suggested this last Tuesday.. 

 I can smell sooo much breakage from this solution. Even though it could
 work  : )

I'm not sure to interpret this as yet another snide remark or not so I'll 
give you the benefit of the doubt and assume you're referring to sets of 
ebuilds that require several slots. Before implementing the above, the tree 
will be checked for any cases where the above idea will fail.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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/down is not infinite ;). Of course there's no chance to
 get this linear (speak: walking down the dependencies once), unless you
 store the information which ebuild depends (or more exactly DEPENDs 
 RDEPENDs) on foo in a list in foo's pkg db entry. The dependency resolution
 of the packages needed to rebuild on top of it is not different as usual.

It's never linear. Changing n doesn't make it so. It just circumventing the 
problem. And what is n here exactly. I'd guess the average number of 
dependencies of a package. This does however not say anything about the depth 
of the tree. We can now however that in most cases based from an empty tree 
(or only a very minimal tree) the total number of packages (and as such 
dependencies) is less than 1000. A number that is well manageable.

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. Detecting that 
can be done by hashtables which have O(log n) complexity on the number of 
packages in the tree. In any case not that expensive.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpqiCW6e2QLJ.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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. Detecting that can be done by hashtables which have
| O(log n) complexity on the number of packages in the tree. In any
| case not that expensive.

Lookups against the tree can be done in O(1) time. That isn't the
issue. The issue is that as soon as you introduce backtracking, you go
to O(n!) with a general try stuff in order algorithm like the one
you proposed, which for 1000 packages is utterly unusable.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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 taken for granted by the other side if it satisfies it's
 | dependencies. Detecting that can be done by hashtables which have
 | O(log n) complexity on the number of packages in the tree. In any
 | case not that expensive.

 Lookups against the tree can be done in O(1) time. That isn't the
 issue. The issue is that as soon as you introduce backtracking, you go
 to O(n!) with a general try stuff in order algorithm like the one
 you proposed, which for 1000 packages is utterly unusable.

Only O(n!) in the worst case. As currently the algorithm does not do 
backtracking it has a O(n) complexity in the number of packages. With the 
current tree, backtracing should never be needed, so in practice nothing is 
left from that O(n!) complexity. The only case for worst case complexity is 
when the matching doesn't work. What we need for that is smart backtracking. 
We should recognize that if version A fails the dependency check, then 
version B can only fix that if it's dependencies differ. And only for those 
dependencies that are different. I'm not clear yet exactly how to do it, but 
it should go along those lines.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpgGzsh90koY.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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?
 
  No! It (and also its dependencies) can be built against each 3.x slot.
 
   As long as the information is represented dependency wise, portage
   should be able to handle it fine.  Just need to have that info there.
 
  It can't be handled dependency wise, because what is interesting is
  against which KDE version the relevant ebuilds are actually installed.

 So note the comment in the email you are responding to about locking
 down the used dep/rdeps for an install.

 Via that, could lock down the slot it was compiled against.  Bit more
 to it then that, but the concerns your raising *again* are not
 use/slot based, your pointing at other portage faults (thus please
 seperate those concerns from use/slot).

I may be missing something, but I can't see how this will resolve Carsten's 
issue. From what I can tell, the ebuilds would be laid out something like:

digikam:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 ) libkipi libkexif
libkipi:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 )
libkexif:DEPEND=|| ( kdelibs:3.5 kdelibs:3.4 )

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 metadata unless you want to overload the meaning of SLOT.

If overloading, dependencies would be flattened (meaning || ( kdelibs:3.5 
kdelibs:3.4 ) would have became kdelibs:3.4 for the original install) 
within the installed package database but there's also there's the 
implication that only one slot of a package be allowed in a connected set of 
nodes. Is that what you're getting at?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 KDE would be needed to 
work with this particular KDE version. Just for the sake of having to match 
with insufficient slot dependencies.

I'll give another example:

Application X works with KDE 4.0 (which implies that it will work with all KDE 
4.x versions). Locking the dependency down to e.g. kde-base/kdelibs:4.0 
implies adding another ebuild revision depending on kde-base/kdelibs:4.1, 
another one on kde-base/kdelibs:4.2. In short: Even having slot dependencies 
they won't be used, because =kde-base/kdelibs-4* is the dependency, which 
matches and no one will add hundreds of ebuilds just to follow the limiting 
scope Portage is providing via slot dependencies.

Based on the packages we have now in Portage, that would mean ~300 additional 
new ebuild revisions as a side effect of every KDE version bump. Simply 
ridiculous.


Carsten


pgptdIP2KO63X.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 via a USE flag rather than linking against
 whichever happens to be there.

Forget it. Not maintainable, doesn't make any sense at all and won't happen. 
And it's not like gtk1/gtk2. An application working with KDE 3.0 works as 
fine with KDE 3.5. gtk1/gtk2 is comparable to KDE 3.x/KDE 4.x.


Carsten


pgpOJXgRK2fLD.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 metadata unless you want to overload the meaning of
 SLOT.

It's not possible to represent that via dependencies. What is needed is some 
sort of introspection which relevant ebuild is built against which KDE 
version and if those _installed_ ebuild:kdever combinations match the one the 
_actual_ ebuild to emerge.

But you're right about the overloading of the meaning of slots, because that's 
happening right now. Slots are used to install several versions of a package 
side by side. The idea Ciaranm and Brian are proposing to lock ebuilds 
depending on slotted packages down to a single slot is the redefinition. And 
once again: This doesn't match reality.


Carsten


pgpJIb6PA58Z0.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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 break digikam. I can't see how it's directly
  represented in the metadata unless you want to overload the meaning of
  SLOT.

 It's not possible to represent that via dependencies. What is needed is
 some sort of introspection which relevant ebuild is built against which KDE
 version and if those _installed_ ebuild:kdever combinations match the one
 the _actual_ ebuild to emerge.

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.

 But you're right about the overloading of the meaning of slots, because
 that's happening right now. Slots are used to install several versions of a
 package side by side. The idea Ciaranm and Brian are proposing to lock
 ebuilds depending on slotted packages down to a single slot is the
 redefinition. And once again: This doesn't match reality.

You've misunderstand what is meant by locking ebuild dependencies. I gave 
you a definition in my second paragraph. Please have a re-read.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 not want to hurt your feelings by underlining, Jason. :) You missed a 
point in your wording of the digikam example in your first paragraph (while 
implied in the second), though. It's not only that libkexif and libkipi need 
to be rebuilt, but any other application (e.g. showimg) depending on them as 
well. 

 You've misunderstand what is meant by locking ebuild dependencies. I gave
 you a definition in my second paragraph. Please have a re-read.

I did not comment on what you wrote, but on Ciaranm's and Brian's ideas about 
using slot dependencies regarding KDE packages.


Carsten


pgpPqXa3zhQjN.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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 = dependencies entirely. Which is a good thing, since
 those atoms make dependency resolution a general-case unsolvable
 problem.

Well, it shouldn't be unsolvable. Choosing can be done with the following 
process:

- Get the list of packages with the requested name.
- Sort the list from the newest version, to the oldest.
- Iterate over the packages:
- Apply all restrictions on the package (including exclusions). If the
  package satisfies all, test it's dependencies recursively.
- If all dependencies match, this package matches the dependency. Continue
  with the next depend atom.
- If no match, iterate the next package.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpHcsngDFnQV.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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 Portage catches it, instead spitting out a weird
 message, leaving the root of the issue in the dark. Should be also simple
 to write a test case.

  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 = dependencies entirely. Which is a good thing, since
  those atoms make dependency resolution a general-case unsolvable
  problem.

 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 same one.
 You simply cannot express this via slot dependencies, so this feature is
 useless for KDE packages.

Yes, this needs more sophisticated ebuild syntax and handling. In general one 
must support dependent dependencies for this. This requires many features 
portage doesn't offer yet. A.o. recording the actual versions that satisfied 
a dependency at compile time.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpLVfMXmW7nj.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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 that many
 people want but most are not evening willing to attempt implementing it.
 What was the purpose of that comment?

To express that based on my experience, I don't expect it to be in production 
before June 2006. I do understand it would take such long though.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpbJi5DUj7Jh.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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
  would require two packages.

 Portage's current behaviour is to consider individual atoms individually,
 but I wouldn't take that to mean it to be the default (as in that all
 atoms must be satisfied individually). Optimal behaviour would be to do as
 little work as possible to adhere to all requirements, making  (or
 ranged deps) unneccessary.

That is true, but my proposal would then still add value in requiring both to 
be satisfied by one and the same package. If you have different syntax 
(perhaps not duplicating the package name) that would be good /better for me.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp6uLWN8jTcd.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 head that'll do it but it goes into an infinite
| loop in the cases that Carsten mentioned. That's why things are
| taking so long. I should really write it down...

It's worse than O(n^n) if you try to do USE dep conflict resolution
too...

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 need the
dep tree today rather than some time next year.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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. Every time a new KDE versions
| comes out a new ebuild revision for every package depending on KDE
| would be needed to work with this particular KDE version. Just for
| the sake of having to match with insufficient slot dependencies.

eclass, and no -r bump.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 linear (speak: walking down the dependencies once), unless you store the 
information which ebuild depends (or more exactly DEPENDs  RDEPENDs) on foo 
in a list in foo's pkg db entry. The dependency resolution of the packages 
needed to rebuild on top of it is not different as usual.


Carsten


pgp3ntoKKjKxX.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 dependencies would break 
caching.


Carsten


pgple7l1HhYiZ.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 speak of to walk up/down is not infinite ;).

Can you prove it, for the allow USE and version cycling case? (Hint:
you may find the PCP somewhat useful...)

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 previous KDE
| version wouldn't be able to install any application.

Sure they would. In the eclass, do something like (untested, buggy,
just a vague proof of concept not real code):

s=
for s_p in ${KDE_NEEDS_PACKAGES} ; do
s_s=
for s_v in 3.3 3.4 4.0 ; do
[[ -z ${KDE_MIN_VER} ]] || version_is_at_least ${KDE_MIN_VER}
s_v || continue
s_s=${s_s} ${s_p}:${s_v}
done
DEPEND=${DEPEND} || ( ${s_s} )
done

| And conditional dependencies would break caching.

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...).

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 (or I do not get what you're after, please 
explain in that case).

- Changed use flags will be processed by the normal dependency calculation of 
the ebuilds to be rebuilt which may lead to additional dependencies or 
blockers. It could also be that some ebuilds are installed, which do not 
exist in the repository anymore.

 you may find the PCP somewhat useful...)

PCP - pretty colored potato? I don't know the abbreviation. Please explain it 
and whatelse I miss in your eyes.


Carsten


pgpzCSIWdJLT9.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 has nothing 
to do with our problem. The question is not listen the possible valid KDE 
versions or a change of the eclass, but the need to know actual used KDE 
version. You'd need to call e.g. kde-config to get it. And this breaks 
caching.


Carsten


pgpmtt63wzs1W.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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=
foo-3.0: DEPEND==foo-1.0
bar-1.0: DEPEND==foo-1.0
baz-1.0: DEPEND==foo-2.0 bar
moo-1.0: DEPEND==foo-3.0 baz

# emerge moo -pv

One solution for this particular case, assuming I didn't get confused
and screw it up:

[n] foo-2.0
[d] foo-1.0
[n] bar-1.0
[u] foo-2.0
[n] baz-1.0
[d] foo-1.0
[u] foo-3.0
[n] moo-1.0

Notice how we have to repeatedly upgrade and downgrade foo.

| - Changed use flags will be processed by the normal dependency
| calculation of the ebuilds to be rebuilt which may lead to additional
| dependencies or blockers. It could also be that some ebuilds are
| installed, which do not exist in the repository anymore.

Again, you can get cycling. This one's even nastier, if you have
various packages that DEPEND upon something built with [foo], various
packages that DEPEND upon something built with [!foo] and upgrade /
downgrade cycling on that package...

|  you may find the PCP somewhat useful...)
| 
| PCP - pretty colored potato? I don't know the abbreviation. Please
| explain it and whatelse I miss in your eyes.

Post's Correspondence Problem. It's a proven general case unsolvable
problem that looks suspiciously similar to the general case dependency
resolution with cycling situation...

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 separate issue...).
| 
| You're trying to solve something which is already solved, but this
| has nothing to do with our problem. The question is not listen the
| possible valid KDE versions or a change of the eclass, but the need
| to know actual used KDE version. You'd need to call e.g. kde-config
| to get it. And this breaks caching.

So you RDEPEND upon the version of KDE against which you were built,
and use the || ( ) flattening feature that's already been proposed.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 off.

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.

 kde-libs/kde:3
 ^^^ need any kde, with slotting enabled.

 kde-libs/kde:3,4
 ^^^ need any kde, slotting 3 or 4.

 Combination?  Not set in stone afaik, the implementation I have
 sitting in saviour doesn't care about the ordering however.

This is the one I'm entirely not sure what it is good for. To me it looks more 
like a workaround for missing dependency ranges, but it won't solve any issue 
for KDE related packages. 

- The dependencies we have are always =kde-libs/kde-x.y and when KDE 4 is 
due, we can change to =kde-libs/kde-3.5* because everything else won't be 
supported anymore. So unless I miss something, kde-libs/kde:X is superfluous.

- What we need is that ebuilds build against KDE slot X force a rebuild of 
those dependencies, which were against KDE slot Y as well as every other 
installed ebuild depending on them. Right now my fugly slot_rebuild() 
workaround lets the user do the job by hand.


As a general remark I'd like to know if and how this enhanced dependency 
syntax is ordered. :[], []: or is both allowed!? What if we find out, that we 
need to consider another factor, later? :[]? Wouldn't it be better to have 
a extensible scheme, like e.g. $category/$ebuild[use:foo,!bar;slot:x,y] ?


Carsten


pgpu4QYUzO1bD.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 they're purely in DEPEND, that one isn't even an incompatability.

|  kde-libs/kde:3
|  ^^^ need any kde, with slotting enabled.
| 
|  kde-libs/kde:3,4
|  ^^^ need any kde, slotting 3 or 4.
| 
|  Combination?  Not set in stone afaik, the implementation I have
|  sitting in saviour doesn't care about the ordering however.
| 
| This is the one I'm entirely not sure what it is good for. To me it
| looks more like a workaround for missing dependency ranges, but it
| won't solve any issue for KDE related packages. 

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 = dependencies entirely. Which is a good thing, since
those atoms make dependency resolution a general-case unsolvable
problem.

| As a general remark I'd like to know if and how this enhanced
| dependency syntax is ordered. :[], []: or is both allowed!? What if
| we find out, that we need to consider another factor, later? :[]?
| Wouldn't it be better to have a extensible scheme, like e.g.
| $category/$ebuild[use:foo,!bar;slot:x,y] ?

The existing syntax is just as extensible. Up the EABI revision, and
start adding new syntax as needed.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 the root of the issue in the dark. Should be also simple to 
write a test case.

 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 = dependencies entirely. Which is a good thing, since
 those atoms make dependency resolution a general-case unsolvable
 problem.

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 same one. You 
simply cannot express this via slot dependencies, so this feature is useless 
for KDE packages. 

 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 call for. I prefer clean data structures.


Carsten


pgpuUpWXh9dlB.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 same one. You simply cannot express this via slot
| dependencies, so this feature is useless for KDE packages. 

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.

|  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 call for. I prefer clean data
| structures.

The proposed syntax is cleaner than shoving arbitrary stuff inside
[bleh]. Any new [role:] tags will require an EABI bump anyway, so
there's no reason to stick to your proposed syntax to avoid future
backwards compatibility breaks.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 call for. I prefer clean data
 | structures.
 
 The proposed syntax is cleaner than shoving arbitrary stuff inside
 [bleh]. Any new [role:] tags will require an EABI bump anyway, so
 there's no reason to stick to your proposed syntax to avoid future
 backwards compatibility breaks.
Expanding a bit...

Via eapi, if we wanted to throw out the syntax down the line we could.

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 bugs.
~harring


pgp1G7nGB2yqm.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 bugs.

Addition of any new dependency filtering criterion is a backwards
incompatible change anyway. If you add, say, [fish:trout] and older
versions of Portage don't recognise [fish:], there's no way for said
older Portage versions to know what to do. Being able to parse
additional DEPEND constructs is not sufficient.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 backwards compatible way, don't use it for 6 months, then deal 
 | with the bugs.
 
 Addition of any new dependency filtering criterion is a backwards
 incompatible change anyway. If you add, say, [fish:trout] and older
 versions of Portage don't recognise [fish:], there's no way for said
 older Portage versions to know what to do. Being able to parse
 additional DEPEND constructs is not sufficient.

Guessing you're missing how EAPI works.  The scenario you're pointing 
at isn't an issue for EAPI aware portage versions.

If portage doesn't know of that EAPI version, it flat out won't do 
_any_ operations on that package; it's filtered out of available 
packages.

Hell, we don't even store the metadata in the cache- the reasoning 
being that if we don't know of that EAPI version, there is _no_ 
gurantee we'll even be processing the metadata dumped from ebuild.sh 
properly (nor that ebuild.sh will produce proper metadata for that eapi).

So... for scenario above, portage sees the differing EAPI, masks the 
package on it's own- the new dependency format isn't seen, nor 
processed by portage.

Like I said, via EAPI we can effectively break whatever we want format 
wise, do a total quick cut over without breaking older eapi aware 
portages (this is the reason eapi exists).

Non eapi aware portage's will be boned, but so it goes.  They're going 
to be progressively more screwed the further we go portage wise 
anyways, so it's something of a lost cause (imo).
~harring


pgp73LMMl2yGl.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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
|  | 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 bugs.
|  
|  Addition of any new dependency filtering criterion is a backwards
|  incompatible change anyway. If you add, say, [fish:trout] and older
|  versions of Portage don't recognise [fish:], there's no way for said
|  older Portage versions to know what to do. Being able to parse
|  additional DEPEND constructs is not sufficient.
| 
| Guessing you're missing how EAPI works.  The scenario you're pointing 
| at isn't an issue for EAPI aware portage versions.

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.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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-2.0[sandbox,!build]
 
  ^^^ need =portage-2.0 merged with sandbox on, build off.
 
 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.

Actually, you just hit upon one of the main reasons use/slot deps 
have taken so damn long.

Jason can state it better, but our resolver basically chooses a single 
path when doing the resolution; if that resolution turns out to be an 
issue during later resolution steps, existing resolver doesn't back 
track and choose a different (valid) path. 

Note the up/down cycling bugs.  Guess how that comes about?

use/slot deps is a combination of depset extension (plus any code that 
deals with depset), and resolver extension so it handles the extension 
of depset properly- namely, getting issues from above handled, trying 
to dig it's way out of use cycles that aren't hard deps, etc.

So... basically, your concern is with the resolver, not use/slot deps 
syntax.


  kde-libs/kde:3
  ^^^ need any kde, with slotting enabled.
 
  kde-libs/kde:3,4
  ^^^ need any kde, slotting 3 or 4.
 
  Combination?  Not set in stone afaik, the implementation I have
  sitting in saviour doesn't care about the ordering however.
 
 This is the one I'm entirely not sure what it is good for. To me it looks 
 more 
 like a workaround for missing dependency ranges, but it won't solve any issue 
 for KDE related packages. 

What are dep ranges?  It's the intersection of any version set's 
specified by common cat/pkgs.  In other words, instead of just 
processing atom by atom, grab the depends, collapse them down into 
cp-version restrictions, _then_ do the search.  The issue you're 
pointing at isn't use/slot dep based, it's resolver based (again). ;)


 - The dependencies we have are always =kde-libs/kde-x.y and when KDE 4 is 
 due, we can change to =kde-libs/kde-3.5* because everything else won't be 
 supported anymore. So unless I miss something, kde-libs/kde:X is superfluous.

Missing something /me thinks.
shouldn't really be specifying =kde-x.y; should be specifying the 
slotting.  Do that, and you wouldn't have to go back and change it 
over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a 
different slot.

Basically... it's how it *should* be done from the get go, rather then 
going back and fixing things via tweaking the scary eclass y'all have. :)


 As a general remark I'd like to know if and how this enhanced dependency 
 syntax is ordered. :[], []: or is both allowed!? What if we find out, that we 
 need to consider another factor, later? :[]?

Like I stated in a previous email, the ordering isn't specified- right 
now we can split upon [] matches to handle it regardless of ordering, 
although I'd think some form of ordering would be wise...

~harring


pgpQWMlk6YWcl.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 of KDE and libs around it) hundreds of duplicated 
ebuilds. In short: Your approach would result in a unmaintainable mess and is 
not going to become reality.

 The proposed syntax is cleaner than shoving arbitrary stuff inside
 [bleh].

You know the disagree thingie. But it's not that I have to ride on it any 
longer.


Carsten


pgp46bUeR5vlY.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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/downgrade cycles with Portage 2.1 as well, but have them confronted with a 
proper error message!? :)

  - The dependencies we have are always =kde-libs/kde-x.y and when KDE 4
  is due, we can change to =kde-libs/kde-3.5* because everything else won't
  be supported anymore. So unless I miss something, kde-libs/kde:X is
  superfluous.

 Missing something /me thinks.
 shouldn't really be specifying =kde-x.y; should be specifying the
 slotting.  Do that, and you wouldn't have to go back and change it
 over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a
 different slot.

Of course slot dependencies are cleaner. Just that they don't address a 
practical problem with ebuilds buildable against multiple slotted ebuilds of 
one packages, but the need to have them, their dependencies and all other 
ebuilds depending on the latter (ones [sp?]) built against one and the same 
ebuild ( In reality a set of ebuilds, named KDE X.Y).


Carsten


pgp3UqdzVqgZc.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 adding a new way 
(§$%€ or so) to describe or latest enhanced dependency atom.


Carsten


pgpRoB1lv8bPN.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 extract from your words that we get rid of ~arch users complains about 
 up/downgrade cycles with Portage 2.1 as well, but have them confronted with a 
 proper error message!? :)

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.


   - The dependencies we have are always =kde-libs/kde-x.y and when KDE 4
   is due, we can change to =kde-libs/kde-3.5* because everything else won't
   be supported anymore. So unless I miss something, kde-libs/kde:X is
   superfluous.
 
  Missing something /me thinks.
  shouldn't really be specifying =kde-x.y; should be specifying the
  slotting.  Do that, and you wouldn't have to go back and change it
  over to =kde-libs/kde-3.5* ; you just mark the new kde-4 as a
  different slot.
 
 Of course slot dependencies are cleaner. Just that they don't address a 
 practical problem with ebuilds buildable against multiple slotted ebuilds of 
 one packages, but the need to have them, their dependencies and all other 
 ebuilds depending on the latter (ones [sp?]) built against one and the same 
 ebuild ( In reality a set of ebuilds, named KDE X.Y).

That sounds more like a failure of the ebuild's dep/rdep 
specification, either that or your hinting at the need to lock down 
the rdep's an ebuild was built against.

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).

~harring


pgpQ2ALMkuOU4.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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


pgpN7HZsGAEfF.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 [fish:] key.
 
 Nooo! ;) I said it would look more consistent, than always adding a new way 
 (§$%€ or so) to describe or latest enhanced dependency atom.
Either way, it's going to require depset extension, and an EAPI bump.

I'd rather deal with it as it comes rather then trying to jam 
everything into it now.  EAPI allows us to do whatever we want once 
portage aware versions are deployed- I'd rather abuse that then make a 
mess of use/slot for syntax I personally dislike. :)

~harring


pgp2NtLa1e2Zu.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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
2. You update to KDE 3.5 

What you now have is the following: KDE 3.5 works fine and Digikam as well, 
just that it uses KDE 3.4 libs. But what happens: A Digikam update (or you 
rebuild for whatever reason). You emerge it (against KDE 3.5), but its 
dependencies (libkipi, libkexif ) are still built against kdelibs 3.4. The 
result is that compiling Digikam fails. You need to rebuild these 
dependencies and every other ebuild depending n those against KDE 3.5. And 
Portage should do that transparently.

For now I have written slot_rebuild() which detects the problem at least and 
provides the user with the information what to do, but it's dead ugly.


Carsten


pgpndvDJCvSD8.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 dependency enhancement without having a Portage version in 
place that can resolve issues as they appeare!?! Scary.


Carsten


pgpPEvkfU9G2N.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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).
 
 O.k.
 
 1. You have KDE 3.4 and Digikam (version doesn't matter) installed
 2. You update to KDE 3.5 
 
 What you now have is the following: KDE 3.5 works fine and Digikam as well, 
 just that it uses KDE 3.4 libs. But what happens: A Digikam update (or you 
 rebuild for whatever reason). You emerge it (against KDE 3.5), but its 
 dependencies (libkipi, libkexif ) are still built against kdelibs 3.4. The 
 result is that compiling Digikam fails. You need to rebuild these 
 dependencies and every other ebuild depending n those against KDE 3.5. And 
 Portage should do that transparently.
 
 For now I have written slot_rebuild() which detects the problem at least and 
 provides the user with the information what to do, but it's dead ugly.

The version of digikam being merged requires slot=3.5- it should be 
depending on libk* slot=3.5, also, no?

As long as the information is represented dependency wise, portage 
should be able to handle it fine.  Just need to have that info there.

If an ebuild dep/rdeps via || (), then we're getting into whether or 
not portage should be filtering || () down to the selected atom...
~harring


pgpxKb6IUuH0e.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 your words. Thanks for destroying my hope in two sentences. ;p
 So we add this dependency enhancement without having a Portage version in 
 place that can resolve issues as they appeare!?! Scary.

Who said anything about this going into portage _without_ the resolver 
enhancements?

Re-read my emails, I've stated the resolver improvements are 
*required* for use/slot to go in (specifically use).

So... yeah, you're not following what I've been saying.
~harring


pgpc9KHL8TcON.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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, portage
 should be able to handle it fine.  Just need to have that info there.

It can't be handled dependency wise, because what is interesting is against 
which KDE version the relevant ebuilds are actually installed.


Carsten


pgpcxU0EbgGdg.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 built against each 3.x slot.

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 via a USE flag rather than linking against
whichever happens to be there.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 each 3.x slot.
 
  As long as the information is represented dependency wise, portage
  should be able to handle it fine.  Just need to have that info there.
 
 It can't be handled dependency wise, because what is interesting is against 
 which KDE version the relevant ebuilds are actually installed.

So note the comment in the email you are responding to about locking 
down the used dep/rdeps for an install.

Via that, could lock down the slot it was compiled against.  Bit more 
to it then that, but the concerns your raising *again* are not 
use/slot based, your pointing at other portage faults (thus please 
seperate those concerns from use/slot).

~harring


pgpCRl3G2aOe0.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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 * in SLOTs at the moment either...

 *shrug* SLOT will have to be tightened up anyway. Otherwise
 SLOT=[foo] will cause terrible confusion.

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 characters in repoman 
in preparation? Anybody see a need for characters beyond those?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 characters in repoman in preparation? Anybody see a need for
| characters beyond those?

+ (and : ?) are allowed in ${PN}, no? Might be wise to allow them in
SLOT too for consistency.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 those of us who
provide the tree, or is the tree expected to be restricted to whatever
Portage developers feel like implementing?

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Dan Meltzer]

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 to go).

 Is Portage development done to support the needs of those of us who
 provide the tree, or is the tree expected to be restricted to whatever
 Portage developers feel like implementing?

I'd say the latter.

The tree is restricted to what is implemented in portage, and as it is
a volunteer organization, what is implemented is what the portage
dev's feel like implementing.

If you want more to be implemented, submit patches.

 --
 Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
 Mail: ciaranm at gentoo.org
 Web : http://dev.gentoo.org/~ciaranm





-- 
gentoo-dev@gentoo.org mailing list

Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Curtis Napier]

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
| it sane/ready to go).

Is Portage development done to support the needs of those of us who
provide the tree, or is the tree expected to be restricted to whatever
Portage developers feel like implementing?



I'd say the latter.

The tree is restricted to what is implemented in portage, and as it is
a volunteer organization, what is implemented is what the portage
dev's feel like implementing.

If you want more to be implemented, submit patches.



hmmm, from reading the emails, bug reports and irc chats of portage 
devs, non-portage devs and end users I would say it's a little bit of 
both. The non-portage devs are using a tool provided by the portage devs 
that allows them to create the Gentoo distro. Those two teams work 
together to ensure the best possible tool. If the portage devs ONLY did 
what they felt like (or the opposite, only did what the other devs told 
them and ignored their own intimate knowledge of portage) then portage 
would not be where it is today. True developement is a subtle play of 
ideas back and forth between everyone involved resulting in an excellent 
piece of software.


Yes, the portage devs have the final say since they are the ones doing 
the actual work but they would be remiss if they simply ignored everyone 
else and did what they wanted (although they could very well do this if 
they choose). Just as the non-portage devs would be remiss if we ignored 
everyone else while doing our work.


The one doing the work is the one with the intimate knowledge of 
internals so their opinion should count very highly when it comes to 
implementing/not-implementing those ideas but not all of the ideas come 
from the portage-devs. Some of the ideas come from the non-portage-dev 
people who use it on a daily basis.


As so many have said, Gentoo is an all volunteer project so you get what 
we have time to give you but we *do* listen to the ideas of others. We 
don't always implement those ideas but we do listen to them at the very 
least. You never know where the next great idea that will make things 
faster/more efficient is going to come from and we would be stupid to 
ignore them.


confucius says: No dev is an island.



--
gentoo-dev@gentoo.org mailing list

Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Dan Meltzer]

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
 | 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 those of us who
 provide the tree, or is the tree expected to be restricted to whatever
 Portage developers feel like implementing?
 
 
  I'd say the latter.
 
  The tree is restricted to what is implemented in portage, and as it is
  a volunteer organization, what is implemented is what the portage
  dev's feel like implementing.
 
  If you want more to be implemented, submit patches.
 

 hmmm, from reading the emails, bug reports and irc chats of portage
 devs, non-portage devs and end users I would say it's a little bit of
 both. The non-portage devs are using a tool provided by the portage devs
 that allows them to create the Gentoo distro. Those two teams work
 together to ensure the best possible tool. If the portage devs ONLY did
 what they felt like (or the opposite, only did what the other devs told
 them and ignored their own intimate knowledge of portage) then portage
 would not be where it is today. True developement is a subtle play of
 ideas back and forth between everyone involved resulting in an excellent
 piece of software.

snip

For the most part, yes.

However, following these same lists, one notices ciaranm always taking
potshots at the portage team, yet never contributing anything useful.
So my previous response was directed primarily at him.

-- 
gentoo-dev@gentoo.org mailing list

Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 sane/ready to go).
 
 Is Portage development done to support the needs of those of us who
 provide the tree, or is the tree expected to be restricted to whatever
 Portage developers feel like implementing?

Personally, I'd state anyone who thinks we're implementing only what 
we find fun to do is trolling something fierce, but I'm also a portage 
dev thus my views are a bit different.

Regardless, ciaran's own statement via irc that the portage devs are 
hurting gentoo by ignoring certain requests still harkens right back 
to my point- if you believe it to be the case, nagging/bitching ain't 
going to improve it in anyway.

People, you've got the source.

You want it and think we're moving to slow/being tools/incompetent 
jackasses, whatever the belief, _you_ can do something about it that 
results in actual progress- I already stated the ways to help in my 
last email.

So... again, you want it, help, or kindly sit back and wait for it to 
be implemented on our timeline.
~harring


pgpcnzm3uK1lH.pgp
Description: PGP signature

Re: how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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/ready to go).

 Is Portage development done to support the needs of those of us who
 provide the tree, or is the tree expected to be restricted to whatever
 Portage developers feel like implementing?

Neither. At least for myself, portage development is done to prioritized 
according to what I see as the needs of users. Needs of those of us who 
provide the tree are prioritized by how much benefit will be translated
to end users combined with how much work will be required.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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 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 consider a

Do those already work then? I'd like to be able to use them.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpkSyKnESIpi.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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:
  |
  | ~  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 it more consistent with the way :slot and [use]
  restrictions work. *shrug* I guess it's down to whether you consider a

 Do those already work then? I'd like to be able to use them.

:slot and [use]? Not yet. I'm sure that once they do the shouts will be 
resounding across the globe such that it would not be possible for you to be 
unaware of it... ;)

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 consider a
| 
| Do those already work then? I'd like to be able to use them.

Not in anything end users should be using. The syntax is pretty much
decided upon though...

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

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] restrictions work. *shrug* I guess it's down to whether
 |  you consider a
 |
 | Do those already work then? I'd like to be able to use them.

 Not in anything end users should be using. The syntax is pretty much
 decided upon though...

Glad that they are comming though. Even though I'd probably not hold my 
breath.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpMr255Sg45r.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Spider (DmD Lj)]

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 be able to use them.
  
   Not in anything end users should be using. The syntax is pretty much
   decided upon though...
 
  Glad that they are comming though. Even though I'd probably not hold my
  breath.
 
 Trolling?


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... ; ) 

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.


Suffice to say, we're still waiting, but more content to hack around and
break the build process theese days.

(finally we can kill use_with !! ) 


//Spider


 --
 Jason Stubbs
-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

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 the thread between all those emails in my 
inbox. I'm interested as well to hear a bit about the proposed enhanced 
dependency syntax.

 (finally we can kill use_with !! )

Why? There're not only autotooled configure scripts, so I don't see how to 
replace it in a generic way. I don't see what this would have to do with 
depending on ( ebuild foo without use flag bar ), either.


Carsten





pgpivOsQ6nOV0.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 that many of us have given up... ; )
 
 He - and I thought I just missed the thread between all those emails in my 
 inbox. I'm interested as well to hear a bit about the proposed enhanced 
 dependency syntax.

dev-lang/python[tcltk]
^^^ need that atom resolved with use flag tcltk enabled

=sys-apps/portage-2.0[sandbox,!build]
^^^ need =portage-2.0 merged with sandbox on, build off.

kde-libs/kde:3
^^^ need any kde, with slotting enabled.

kde-libs/kde:3,4
^^^ need any kde, slotting 3 or 4.

Combination?  Not set in stone afaik, the implementation I have 
sitting in saviour doesn't care about the ordering however.


  (finally we can kill use_with !! )
 
 Why? There're not only autotooled configure scripts, so I don't see how to 
 replace it in a generic way. I don't see what this would have to do with 
 depending on ( ebuild foo without use flag bar ), either.

assume he meant built_with_use

~harring


pgpvWuwLg77mB.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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 [EMAIL PROTECTED]
   
| Do those already work then? I'd like to be able to use them.
   
Not in anything end users should be using. The syntax is pretty much
decided upon though...
  
   Glad that they are comming though. Even though I'd probably not hold my
   breath.
 
  Trolling?

 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... ; )

Yep, bug 2272.

 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 that many people 
want but most are not evening willing to attempt implementing it. What was 
the purpose of that comment?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 tightened up anyway. Otherwise
SLOT=[foo] will cause terrible confusion.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 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 be able to use them.

 Not in anything end users should be using. The syntax is pretty much
 decided upon though...
   
Glad that they are comming though. Even though I'd probably not hold my
breath.
  
   Trolling?
 
  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... ; )
 
 Yep, bug 2272.

(still was trolling).

  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 that many 
 people 
 want but most are not evening willing to attempt implementing it. What was 
 the purpose of that comment?

Expanding on this since jason's email is quite a bit nicer then my 
original response.  Frankly... the potshot at portage is mild 
bullshit, but at this point I'm getting accustomed to it- bit easier 
to take a swipe at portage rather then to do actual work 
improving things (low blow potentially, but it sure as hell seems to 
be the case).

If folks are looking to get this feature, here's how you scratch that 
itch.

1) design and implement your own stable based patch that is 
maintainable.
2) help complete the saviour branch which holds a massive 
refactoring (including use/slot required refactoring).  Use/Slot is 
already sitting in that branch btw, although the resolver handling of 
it (ability to dig itself out of use cycles) isn't there yet.
3) help with the day to day bug mangling, regression fixes, and 
general maintenance.  Or work on the small features that need to be 
dealt with; either way, help reduce the load so existing portage devs 
can implement the beast.

Note that nowhere in that list, is nagging/snarky comments/general 
asshattery on public ml's listed as a means to get what you want.  

That's actually something of a negative contribution, since time is 
spent sending pissy emails such as this, or just results in 
people saying screw portage work.  Devs making noise, you know what 
the scenario is, you're on the receiving end of it too for your area 
of work.  Portage is no different.

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).  It's been 3 years for the bug- more then ample 
time to have contributed for some of the devs complaining in this 
thread.

Chip in, or bite your tongue essentially.
~harring


pgp8Y001vliBX.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Zac Medico]

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 Display-If-* headers insufficient for some 
reason?


Looking into this a little further, it seems that Display-If-Installed can be 
implemented with `portageq match / atom` and Display-If-Keyword can be 
implemented with `portageq envvar ARCH`.  That leaves Display-If-Profile which may 
require a new portageq query in order to cleanly retrieve the profile.  Perhaps 
something like profile=$(portageq profile) would be sufficient?

Zac
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 /
| atom` and Display-If-Keyword can be implemented with `portageq
| envvar ARCH`.  That leaves Display-If-Profile which may require a new
| portageq query in order to cleanly retrieve the profile.  Perhaps
| something like profile=$(portageq profile) would be sufficient?

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 : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Zac Medico]

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 some type of UUID for a package, such as a hash of the ebuild.  That 
way, the hash from /var/db/pkg could be compared to the hash from the repo that 
has the news item.  If the hashes don't match, then the news item is irrelevant.

Zac
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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?
| 
| Well, probably not.  Off hand, perhaps portageq could provide a query
| that returns some type of UUID for a package, such as a hash of the
| ebuild.  That way, the hash from /var/db/pkg could be compared to the
| hash from the repo that has the news item.  If the hashes don't
| match, then the news item is irrelevant.

Now do you see why I don't want to touch multi repo support without a
proper specification describing how it'll work? :)

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 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 some type of UUID for a package, such as a hash of the
 | ebuild.  That way, the hash from /var/db/pkg could be compared to the
 | hash from the repo that has the news item.  If the hashes don't
 | match, then the news item is irrelevant.
 
 Now do you see why I don't want to touch multi repo support without a
 proper specification describing how it'll work? :)

Multi repo support is actually pretty simple, and doesn't require yet 
another glep/spec/paperwork- it's been sitting in the saviour branch 
for as long as the domain class has existed (3+ months); stand alone 
repository support (matching within that repo) is a resolver thing, 
where we're at in saviour is normal PORTDIR capabilities for all 
specified repo's (standalone, overlay, or otherwise).

It's not that bloody hard to get it working- all of the noise here is 
about further additions to it (which is fine, but kindly rememeber 
that fact), noise which I'd *rather* see resolved down the line.  Why?  

Frankly, the majority of this is portage internal crap.  Either 
extension of portageq api, or extension of atom syntax.

Unique ID's per packages isn't a good idea offhand.  What's needed for 
the comments above is the ability to search installed pkg db's for 
pkgs yielded from repo ID x.  Enter the restriction subsystem.  Add a 
repo level matching class, and you've got the search right there.  
Pretty simple, actually, and not requiring yet another glep for 
saviour.

Back in the land of stable, here's how it should be done-
portageq root atom [repo id]

ex:
portageq / sys-apps/foo break my gentoo

simple mod.  Lack of repo id is old rules, match anything and 
everything.  This actually can be implemented *now* without requiring 
a bunch of handwaving about specs/gleps.

Next issue?
~harring


pgp1aAP8lv5g0.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Danny van Dyk]

-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 it lets you do things like (syntax made up):
|
|DEPEND==foo-bar/baz-2.1::ciaranmssekritrepo
|
|
| Well lets return to normal syntax for a moment.
| DEPEND==foo-bar/baz-2.1
| And lets assume this package is named blar because I enjoy that name.
|
| 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.
No, it doesn't. How would you add repository-specific items to
/etc/portage/package.* ?

Futher, imagine this: The gentoo-x86 repo is split into, say, 4
repositories: gentoo-{system,base,desktop,games}. How would you
reference DEPENDs from one repo to the other in this case?

An optional namespace modifier for *DEPENDS is Good Thing(tm) in my
eyes, and I'd really appreciate it being added to portage rather sooner
than later.

Just one remark: What about making the syntax a bit more familiar to C++
users:

~  DEPENDS=gentoo-foo::foo-bar/baz-2.1

Comments?

Danny
- --
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDooISaVNL8NrtU6IRAshlAKCKAolTb0XsgiO8c3dlw23e0fvdgACgkELL
S5i83H5SZvsDXL55JJLCzqw=
=gnt7
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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, however...
| 
| I don't see the need for this. Resolution will the same repository to
| satisfy a package's dependencies where possible. If you just want to
| be able to state that a package from one repository needs packages
| from a different repository, wouldn't something like
| REPO_URI=mirror://gentoo/repo suffice just as well without making a
| mess of the atom syntax?

Yick. Consider the following use case (picking Vim because I know the
package and can think of an easy, clear example):

Fred builds a repository containing some Vim plugins that aren't in the
main tree. Fred lets other people use this repository. Then, Fred tries
to make an ebuild that needs Vim built with tclinterp enabled. Problem!
The Gentoo ebuilds don't turn on (even via USE) tclinterp. So, Fred
creates his own Vim ebuilds that do support tclinterp. Now he needs
some way to DEPEND upon my Vim ebuilds, not the Gentoo ones.

Now consider the following use case for why if a package is already
installed, try to restrict future installs to packages from that
repository is less than ideal:

A collection of bleeding edge users creates a repository containing
updated ebuilds for unstable Gnome 2.30_alpha releases. Various people
use this repository. Then, the official Gentoo ebuilds for Gnome 2.30
stable are released, and the bleeding edge users don't update their
repository. Users who were previously using the 2.30_alpha ebuilds will
be stuck with them.

So, default behaviour should be pick from any repository, but it
should be as easy as reasonably possible for both ebuilds and users to
specify a repository restriction where necessary or desired.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 it more consistent with the way :slot and [use]
restrictions work. *shrug* I guess it's down to whether you consider a
repository to be a top level object that contains categories, or
whether you view your package db as the union of all stuff in all
repositories, and have the repository restriction as a restriction.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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.

Standalone doesn't fit in with the way things can be used. For any
non-trivial case there will be inter-repository dependencies. Why not
view your collection of available packages as the union of packages
available in any repository instead?

| 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 repo isn't a hold 
| up for glep42.  What is an issue with glep42 is planning for N repos, 
| eg another level of dirs/indirection as has already been stated.

The holdup for GLEP 42 is that you're trying to demand that it supports
some arbitrary future extension to Portage without specifying how that
extension will work.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Zac Medico]

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 repo isn't a hold 
| up for glep42.  What is an issue with glep42 is planning for N repos, 
| eg another level of dirs/indirection as has already been stated.


The holdup for GLEP 42 is that you're trying to demand that it supports
some arbitrary future extension to Portage without specifying how that
extension will work.



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. :)

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 
newsdir gentoo)?

Zac
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Dan Meltzer]

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 this working


On 12/16/05, Ciaran McCreesh [EMAIL PROTECTED] wrote:
 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 some random thing that they might introduce in the future. I tell
 them no, unless they be a lot more specific about what said random
 thing is going to be.

 | 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 newsdir
 | gentoo)?

 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.

 --
 Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
 Mail: ciaranm at gentoo.org
 Web : http://dev.gentoo.org/~ciaranm





-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Zac Medico]

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 newsdir
| gentoo)?

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 '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 can be found.

Zac
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Dan Meltzer]

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 game
  | and just settle on something like newsdir=$(portageq newsdir
  | gentoo)?
 
  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 '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 can be found.

uhh, isn't this kind of circular?

It gets the repo identifier from the files in the repo... oh wait

 Zac
 --
 gentoo-dev@gentoo.org mailing list



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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
| '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 can be found.

This still leaves us with the what are the identifiers and how do we
use them? problem, 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.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Zac Medico]

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, '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 can be found.

This still leaves us with the what are the identifiers and how do we use 
them? problem,


For the time being, the type of functionality provided by gensync could be 
added to portage.  The portage news add-on would need a way to retrieve an 
enumeration of repo identifiers (another portageq query) for use when updating 
the news-*.unread files.


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 Display-If-* headers insufficient for some reason?

Zac 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Zac Medico]

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 can be found.



uhh, isn't this kind of circular?

It gets the repo identifier from the files in the repo... oh wait




The glep specifies /var/lib/gentoo/news/news-*.unread which are created by the 
portage news add-on.  However, yes, it seems that we will need a new portageq 
query in order to enumerate the list of repo identifiers.

Zac
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Luca Barbato]

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 sensible
|option, since it lets you do things like (syntax made up):
|
|DEPEND==foo-bar/baz-2.1::ciaranmssekritrepo
|
|
| Well lets return to normal syntax for a moment.
| DEPEND==foo-bar/baz-2.1
| And lets assume this package is named blar because I enjoy that name.
|
| 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.
No, it doesn't. How would you add repository-specific items to
/etc/portage/package.* ?

Futher, imagine this: The gentoo-x86 repo is split into, say, 4
repositories: gentoo-{system,base,desktop,games}. How would you
reference DEPENDs from one repo to the other in this case?

An optional namespace modifier for *DEPENDS is Good Thing(tm) in my
eyes, and I'd really appreciate it being added to portage rather sooner
than later.

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


lu

--

Luca Barbato

Gentoo/linux Developer  Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

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 categories.
~harring


pgp2Lc90jY8vS.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 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 it lets you do things like (syntax made up):

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, however...

Incidentally, the ::repo syntax (or whatever) would also be useful in
the world file, along with :slot. So something like:

foo-bar/baz:2::ciaranmssekritrepo

would tell the package manager that you want baz SLOT 2 from
ciaranmssekritrepo.

*shrug* But it seems the Portage guys want repository names to be
user-assigned, which makes them far less useful.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Curtis Napier]

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 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 it lets you do things like (syntax made up):

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, however...

Incidentally, the ::repo syntax (or whatever) would also be useful in
the world file, along with :slot. So something like:

foo-bar/baz:2::ciaranmssekritrepo

would tell the package manager that you want baz SLOT 2 from
ciaranmssekritrepo.

*shrug* But it seems the Portage guys want repository names to be
user-assigned, which makes them far less useful.



This functionality would come in very very handy. Would user assigned 
repository names be able to mimic this functionality somehow?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Andrew Muraco]

Curtis Napier wrote:


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 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 it lets you do things like (syntax made up):

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, however...

Incidentally, the ::repo syntax (or whatever) would also be useful in
the world file, along with :slot. So something like:

foo-bar/baz:2::ciaranmssekritrepo

would tell the package manager that you want baz SLOT 2 from
ciaranmssekritrepo.

*shrug* But it seems the Portage guys want repository names to be
user-assigned, which makes them far less useful.

This functionality would come in very very handy. Would user assigned 
repository names be able to mimic this functionality somehow?


What about giving each repo an identifier? That way repos with ebuilds 
can have the repo_id in the ebuilds and not have to worry, repo_ids 
would take precedence when in conflict. Identifiers would just be 
provided for user-stuff, like ex # emerge sync MyRepo or # emerge -av 
MyRepo://foo ? [foo being the name of a package in repo tree with the 
identifier of MyRepo]


what about having a portage config file
/etc/portage/repositories:
priority MyRepo,gentoo

repository {
   identifer = gentoo
   rsync= rsync://../
   repo_path= /usr/portage
}
repository {
   identifer = MyRepo
   rsync= rsync://../
   repo_path= /usr/MyRepoTree
}

(an example for someone that wants to have MyRepo be prefered over 
gentoo tree)


Just tossing out ideas,

Andrew Muraco

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 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 it lets you do things like (syntax made up):
 
 DEPEND==foo-bar/baz-2.1::ciaranmssekritrepo
 
Well lets return to normal syntax for a moment.
DEPEND==foo-bar/baz-2.1
And lets assume this package is named blar because I enjoy that name.

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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ6JSdWzglR5RwbyYAQJsbg/7B8XgQlR6bcTOyeLG2IrguyDh9HJJfhlP
HtiypusFdXF35mFhS469Tsc/dIXPCFbVf7OnflO+m7MCiwryQu19v58R+K5dZgli
lkObsiLmafsdXLE5TGlJ7CuB0yboHrjR/hT8n7tomRuQ/g4YcpvCCL96eSlaQ5iX
tpebI/U0VzOHayoWeGXeMp4oEN197eSg4IM8Q5TQgwh84boDnj/gZAuY11g0nUCL
l3Ardv1qjWHwhmVDnKSxF6fR6EAug0ldNNFL94+xRw1r9Z9pIchC4OO90SBRx6dl
MuwvQLCo9N+HaZgztcXUR0uUFE2H7sTjTVHiIW4KUfZYvoslvNRq9SLBCkn39fQp
LSO4cIpKq81Tov7Ngk/bx7NYfcwv34X6q0ezKCfE4ZYdilST0189Jd6NN2/SiGy6
HOdQh1YWre2jQbcS54Z7p+DSOX6XBg3yUQZTtxDKlaP4vTJdMVjUgqSXdLGFCnGV
suDshDnNQY4opFzmu158U36vX10H5DLqLTTlrJ+3igzb9msnQ/CVnT+lbUFACpq2
DzrBOuJBJcCq+5KPoBk295VozOILjK2hGo+uLLqhA43G4K+mxOD1ER1SOo4osfF2
YBU26fhm14Xxzcf64MtOKB5EzaewX12uzBPFh/a3Ps9VEWCOadhELO0xSENm+ewP
CwxPxIcmsTw=
=HKbW
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

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 able to package.mask things in a given
repository, and it stops you from being able to stick to a given
repository for world entries, and it stops you from being able to use
it in all those zillion other locations where you can currently use a
dep atom to do something useful.

Really, emerge blar::ciaranmssekritrepo with Portage creating the
'restricted' world entry (and the same behaviour for SLOT deps) would
be so much more useful...

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Alec Warner]

-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 the ability to specify repositories in
 | DEPEND.
 
 ...and it stops you from being able to package.mask things in a given
 repository, 
Ideally there will be per-repo package.mask entries as well, since .mask
files are typically repository-based.

 and it stops you from being able to stick to a given
 repository for world entries, and it stops you from being able to use
/var/lib/portage/world sucks on the whole.
 it in all those zillion other locations where you can currently use a
 dep atom to do something useful.
Anything in particular other than those other useful things?
 
 Really, emerge blar::ciaranmssekritrepo with Portage creating the
 'restricted' world entry (and the same behaviour for SLOT deps) would
 be so much more useful...
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ6JXY2zglR5RwbyYAQLnNA//W12tpNkaXMZ3y3qVKvOX2SsP/5gem/vY
wZHeUn/h0zYFJ4cMvo/+at2Q6/+c4lIqpac8ihoxJowJX4UnXECk29vHRsZVOcMm
GzO6aiB0MHd+IdBV/yLc3g8gLP2qOaFPIhnGzZw5wG87+nh6x4E9enZ50akgViSN
gpYNF6fPhvjio7ugTYiXSyf3ScVWq/LP/Cf8TI4Dj9QeoeO/Lfg3sEq93JysctZs
XxpiazkHk4X8p0Gpk62PCwEtk/uA/VYC8+4JysMi1t3UZyqcghREVNRzNu7w8ErU
eonwty/PANReP9f74i7l6cV9y/HTrkkmmh/hxWhKqnuXAkki208D58f5vrkgTr/h
nk41lWAQ0neh2sBQ4EPs8X7SjVgrxYnsZRicWDa7LosZpSOQwb47XZYZyHvTS0/z
LyMaHC5JniGHis8XGOeI9nLnTRsiItoF+6DK15t8Pel2RyE2FsgkZWCwU0w4s8QE
yC8d9ZW2/nim205jqDlpIZZJIQw7d1RAA+FTJNxDrlcSbxK/AjTajOajdY7wRU22
rmGMrkhXyXnIB6lmiwPYzYHoUi0SoJ8NwurjghjhePNGDfPbyVzKJmlaz9Hz3mo3
Z796P05FPW+EwiNv9MYAfXz5ImgSAmWekUcdiCl5VmWnqfNq+GW6q4fDB1z+f205
fD5eCWHusmk=
=XC8n
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list