[gentoo-dev] Multiple Repo Support

[gentoo-dev] Multiple Repo Support

[Andrew Muraco]

As i sit reading the current list of list emails about GLEP 42 I see 
that the topic of Multiple Repos coming up over and over again. I wanted 
to ask to see where that support is, and based on what feedback help 
move along so that a standard can be produced. So, now with a few short 
questions:

1. Would Multiple Repo support be GLEP worthy?
1.1. If so, Should I write a GLEP, or poke at some dev to do it? (i'm 
more then willing and able to write a GLEP if that is what is required.)
2. What choices/options are on the table for this feature?
2.1. Which routes are more likely to be implemented?
2.2. Which method would you like to see?
2.3. Does backwards compatiblity really matter, as long as it doesn't 
break people that are using older portage? (ex. once portage is upgraded 
it will move x to y/x and so older versions wouldn't work, but since 
only the new version would be installed it wouldn't be an issue.)

Now, that I've asked for some information I want to share one (hackish, 
I guess) way that it could be done with minimal changing.

in /etc/make.conf:
RSYNC_REPONAME="rsync://.../"
with RSYNC=" .." being defaultly called 'gentoo' or 'portage'

that REPONAME would be used for the tree's folder name
/usr/repositories/REPONAME/

and 'emerge sync REPONAME' would sync only that repo, or 'emerge sync 
[all]' would sync all

Anyways, thats just a quick thought I had on the topic.

Flames, comments, questions  (and answers) welcome
Andrew Muraco


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <tuxp3@leetworks.com>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Curtis Napier]

Ciaran McCreesh wrote:
> On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <tuxp3@leetworks.com>
> 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 <tuxp3@leetworks.com>
>> 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 <tuxp3@leetworks.com>
> 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]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <warnera6@egr.msu.edu>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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 <warnera6@egr.msu.edu>
> 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

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 <kugelfang@gentoo.org>
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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

4am, pardon typos...

On Fri, Dec 16, 2005 at 03:56:30AM +0000, Ciaran McCreesh wrote:
> On Thu, 15 Dec 2005 22:34:05 -0500 Andrew Muraco <tuxp3@leetworks.com>
> 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):
> 
<snip>
> 
> *shrug* But it seems the Portage guys want repository names to be
> user-assigned, which makes them far less useful.

You seem confused.

Unique repo ID added to atoms?  Bit bastardly imo, but that's 
needed down the line at some point- extension of depset syntax either 
way isn't a hold up on true portage N repo support.  Makes it a 
helluva lot more useful, but just making it clear that N repo doesn't 
require depset extension, such an extension would be a feature, not 
a req.


Either way... minor comment on existing, and what's needed/intended.

Existing /etc/portage/package.* layout is inherintly single repo in 
design- bastardizing the atom spec just to resolve that is daft.

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.  Config design that's sitting in savior actually handles 
this (eg, you can bind whatever crazy set of package.* visibility filters 
you like per repo), *although* it _requires_ the user to uniquely 
identify the repo.  Why?  Well portdir as a magic constant doesn't cut 
it in a potentially N repo environment.

Why is this a user configurable option?

User's choice for emerge --repo ${repo_label} sync.

This in no way blocks an internal repo ID being used- it's _merely_ 
the local name that's bound to the repo, thus please stop the "user 
configurable repo labels is stupid" angle, since it's effectively 
the user facing alias/handle.

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.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

On Friday 16 December 2005 14:57, Alec Warner wrote:
> Ciaran McCreesh wrote:
> > On Fri, 16 Dec 2005 00:36:54 -0500 Alec Warner <warnera6@egr.msu.edu>
> >
> > 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.

Exactly.

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

The plan is to tag what repo a package came from into the installed package 
database if I understand correctly.

> > 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"?

On Friday 16 December 2005 12:56, Ciaran McCreesh 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?

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

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

On Sat, 17 Dec 2005 00:19:41 +0900 Jason Stubbs <jstubbs@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <kugelfang@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On Fri, 16 Dec 2005 04:12:08 -0800 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On Fri, 16 Dec 2005 13:18:45 -0800 Zac Medico <zmedico@gmail.com> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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 <ciaranm@gentoo.org> wrote:
> On Fri, 16 Dec 2005 13:18:45 -0800 Zac Medico <zmedico@gmail.com> 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 <zmedico@gmail.com> 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]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Fri, 16 Dec 2005 16:42:53 -0500 Dan Meltzer
<parallelgrapefruit@gmail.com> wrote:
| Why not $(portageq newsdir) ?  Currently, that would return only the
| one for main tree, but if/whenever multi repo support it added, it
| could return a space delimted list.  This makes it simple to manage,
| and lets the portage crew
| a) figure out what they want to do
| b) implement it while keeping this working

Doesn't provide the necessary identifier names.

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On Fri, 16 Dec 2005 14:17:13 -0800 Zac Medico <zmedico@gmail.com> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Zac Medico]

Ciaran McCreesh wrote:
> On Fri, 16 Dec 2005 14:17:13 -0800 Zac Medico <zmedico@gmail.com> 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]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Sat, 17 Dec 2005 12:38:24 -0800 Zac Medico <zmedico@gmail.com> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico <zmedico@gmail.com> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

On Sat, Dec 17, 2005 at 09:21:45PM +0000, Ciaran McCreesh wrote:
> On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico <zmedico@gmail.com> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Multiple Repo Support

[Duncan]

Zac Medico posted <43A48014.1080000@gmail.com>, excerpted below,  on Sat,
17 Dec 2005 13:16:04 -0800:

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

Ebuild hashes certainly would /not/ work, because existing ebuilds are
routinely changed (thereby changing the hash) after initial appearance in
the tree, while keeping the same ebuild -rX number (thus, the same
filename, the same ebuild).  Policy (as understood here, noting that I'm
not a dev) is that the revision can remain the same if it's not something
that's going to majorly effect users who have already merged the existing
version. Thus, for example, changes to the ebuild that only fix bugs that
kept it from building on specific system configurations don't warrant a
revision bump, because that doesn't affect those who /were/ able to merge
it. Creating a revision bump in that case simply forces them to do more
unnecessary updating (assuming they keep reasonably updated in the first
place).  Of course, a security revision or patch that adds functionality
for existing users, should normally get a -rX bump, while upstream bumps
of course correspond to bumps as well.

Brian's comment that news should be repository specific makes the most
sense to me, thereby eliminating the need for ebuild UUIDs for the
purposes of news, anyway. However, were they to be needed, they would
almost certainly be implemented as yet another variable in the ebuild, as
that would at once separate ebuild changes from UUID changes, and be
relatively simple to implement, given the number of other variables
already parsed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Friday 16 December 2005 18:54, Ciaran McCreesh wrote:
> On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <kugelfang@gentoo.org>
>
> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <pauldv@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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 <kugelfang@gentoo.org>
> >
> > 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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

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 <pauldv@gentoo.org>
> >
> > 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.

Trolling?

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

Re: [gentoo-dev] Multiple Repo Support

[Spider (DmD Lj)]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

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 <pauldv@gentoo.org>
> > > | 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

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




[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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 <pauldv@gentoo.org>
> > > >
> > > > | 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

[Jason Stubbs]

On Saturday 24 December 2005 10:25, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <ferringb@gentoo.org>
>
> wrote:
> | kde-libs/kde:3
> | ^^^ need any kde, with slotting enabled.
> |
> | kde-libs/kde:3,4
> | ^^^ need any kde, slotting 3 or 4.

I'd prefer to not have this last one. It can be done as "|| ( kde-libs/kde:3 
kde-libs/kde:4 )" whereas all other atom constructs are already at their most 
minimalistic form.

> Will foo-bar/baz:3* or foo-bar/baz:3.* work?

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

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

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Sat, 24 Dec 2005 12:50:33 +0900 Jason Stubbs <jstubbs@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

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 <pauldv@gentoo.org>
> > > > >
> > > > > | 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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 <jstubbs@gentoo.org>
>
> 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]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Sat, 24 Dec 2005 17:57:30 +0900 Jason Stubbs <jstubbs@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Dan Meltzer]

On 12/24/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <ferringb@gentoo.org>
> 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 <ciaranm@gentoo.org> wrote:
> 
>>On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <ferringb@gentoo.org>
>>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.
> 

hmmmmmmm, 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 <curtis119@gentoo.org> wrote:
> Dan Meltzer wrote:
> > On 12/24/05, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> >
> >>On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <ferringb@gentoo.org>
> >>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.
> >
>
> hmmmmmmm, 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]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

On Sat, Dec 24, 2005 at 05:33:06PM +0000, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 23:56:37 -0800 Brian Harring <ferringb@gentoo.org>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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 <ferringb@gentoo.org>
>
> 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

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Tue, 27 Dec 2005 01:33:13 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Tue, Dec 27, 2005 at 12:46:49AM +0000, 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <ferringb@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

On Tue, Dec 27, 2005 at 01:03:49AM +0000, Ciaran McCreesh wrote:
> On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring <ferringb@gentoo.org>
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

On Mon, 26 Dec 2005 17:17:54 -0800 Brian Harring <ferringb@gentoo.org>
wrote:
| On Tue, Dec 27, 2005 at 01:03:49AM +0000, Ciaran McCreesh wrote:
| > On Mon, 26 Dec 2005 16:57:07 -0800 Brian Harring
| > <ferringb@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3300 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Tue, Dec 27, 2005 at 02:31:02AM +0100, Carsten Lohrke wrote:
> On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote:
> > You solve this either by SLOTting bar and making each bar SLOT use a
> > SLOT dep upon KDE, or by using USE flags and [use]:slot deps.
> 
> It's not a that uncommon case 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.

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

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Tue, 27 Dec 2005 03:54:38 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Saturday 24 December 2005 04:50, Jason Stubbs wrote:
> On Saturday 24 December 2005 10:25, Ciaran McCreesh wrote:
> > On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <ferringb@gentoo.org>
> >
> > wrote:
> > | kde-libs/kde:3
> > | ^^^ need any kde, with slotting enabled.
> > |
> > | kde-libs/kde:3,4
> > | ^^^ need any kde, slotting 3 or 4.
>
> I'd prefer to not have this last one. It can be done as "|| (
> kde-libs/kde:3 kde-libs/kde:4 )" whereas all other atom constructs are
> already at their most minimalistic form.
>
> > Will foo-bar/baz:3* or foo-bar/baz:3.* work?
>
> 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...

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.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On Monday 26 December 2005 21:28, Ciaran McCreesh wrote:
> On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <carlo@gentoo.org>
> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

> On Monday 26 December 2005 21:28, Ciaran McCreesh wrote:
> > On Mon, 26 Dec 2005 21:09:31 +0100 Carsten Lohrke <carlo@gentoo.org>
> > 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.

There's a lot of "should"s that are "aren't"s in there, but in principle that 
is a very elegant idea.

On Wednesday 28 December 2005 00:48, Paul de Vrieze wrote:
> 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.
        ^^^ This step fails. When the set of restrictions cannot be resolved, 
            you need to backtrack and try a lesser version of a previous 
            package hence the set of "all restrictions" is constantly in flux.
>     - If all dependencies match, this package matches the dependency.
> Continue with the next depend atom.
>     - If no match, iterate the next package.

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

</plea for help?>

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

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Wed, 28 Dec 2005 01:20:50 +0900 Jason Stubbs <jstubbs@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

On Tue, 27 Dec 2005 16:48:55 +0100 Paul de Vrieze <pauldv@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Tue, 27 Dec 2005 14:05:21 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

On Tue, 27 Dec 2005 18:37:05 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Tue, 27 Dec 2005 18:44:01 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On Tue, 27 Dec 2005 19:27:01 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <carlo@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Wed, 28 Dec 2005 16:36:28 +0100 Paul de Vrieze <pauldv@gentoo.org>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Wednesday 28 December 2005 16:42, Ciaran McCreesh wrote:
> On Wed, 28 Dec 2005 16:36:28 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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 +0000, Ciaran McCreesh wrote:
> > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <carlo@gentoo.org>
> >
> > 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

[Spider (DmD Lj)]

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

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 +0000, Ciaran McCreesh wrote:
> > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <carlo@gentoo.org>
> > >

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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 +0000, Ciaran McCreesh wrote:
> > > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <carlo@gentoo.org>
> > >
> > > 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)]

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]