[gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[lxnay]

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

Hi there,
app-admin/equo (sabayon overlay -- Entropy Framework client) supports
the postfix "@repository" to let users force the installation of a
package from a specific repository.
Users of multiple repositories seem to appreciate the freedom that is
brought with this small-but-effective(TM) feature.
So what about doing the same in Portage?

Rationale:

User should be able to force the installation of atoms from specific
overlays without worrying too much if others or the main tree feature
a greater release.
Feature-testing overlay maintainers can make sure that packages are
pulled in from their "sources", which could potentially contain
reworked/improved/critically-changed ebuilds.

Adding "@overlay" atoms/deps postfix support could really make life
easier, especially because forcing specific atoms in *DEPEND hoping
that these will be always pulled in from the same overlay is not
something reliable, as you already know.

Examples:

 app-foo/foo@overlay
 app-foo/foo:2@overlay
 foo:2@overlay
 foo@overlay

Comments are welcome, flames are not.

-- 
Fabio Erculiani


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Ciaran McCreesh]

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

On Sun, 24 May 2009 19:04:08 +0200 (CEST)
lxnay@sabayonlinux.org wrote:
> app-admin/equo (sabayon overlay -- Entropy Framework client) supports
> the postfix "@repository" to let users force the installation of a
> package from a specific repository.

@ is used by Portage for sets. Paludis has been using ::repo for repo
dependencies for years. Why not go with the established syntax?

> Users of multiple repositories seem to appreciate the freedom that is
> brought with this small-but-effective(TM) feature.

Note that Portage doesn't support multiple repositories, so this one's
probably not very straight-forward... It supports overlays, which means
only one thing is ultimately visible for a c/p-v.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[lxnay]

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



On Sun, May 24, 2009 at 7:03 PM, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 24 May 2009 19:04:08 +0200 (CEST)
> lxnay@sabayonlinux.org wrote:
>> app-admin/equo (sabayon overlay -- Entropy Framework client) supports
>> the postfix "@repository" to let users force the installation of a
>> package from a specific repository.
>
> @ is used by Portage for sets. Paludis has been using ::repo for repo
> dependencies for years. Why not go with the established syntax?

I wrote "postfix" not "prefix". Sets use "@" prefix.
Regarding your "why", why not going through GLEP and gentoo-dev acceptance ;) ?

>
>> Users of multiple repositories seem to appreciate the freedom that is
>> brought with this small-but-effective(TM) feature.
>
> Note that Portage doesn't support multiple repositories, so this one's
> probably not very straight-forward... It supports overlays, which means
> only one thing is ultimately visible for a c/p-v.

I know.

>
> --
> Ciaran McCreesh
>

I am wondering if enabling @overlay postfix support could be just restricted to command line arguments, at least for the beginning.

-- 
Fabio Erculiani


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Tiziano Müller]

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

Am Sonntag, den 24.05.2009, 20:04 +0200 schrieb lxnay@sabayonlinux.org:
> 
> On Sun, May 24, 2009 at 7:03 PM, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Sun, 24 May 2009 19:04:08 +0200 (CEST)
> > lxnay@sabayonlinux.org wrote:
> >> app-admin/equo (sabayon overlay -- Entropy Framework client) supports
> >> the postfix "@repository" to let users force the installation of a
> >> package from a specific repository.
> >
> > @ is used by Portage for sets. Paludis has been using ::repo for repo
> > dependencies for years. Why not go with the established syntax?
> 
> I wrote "postfix" not "prefix". Sets use "@" prefix.
> Regarding your "why", why not going through GLEP and gentoo-dev acceptance ;) ?
> 
> >
> >> Users of multiple repositories seem to appreciate the freedom that is
> >> brought with this small-but-effective(TM) feature.
> >
> > Note that Portage doesn't support multiple repositories, so this one's
> > probably not very straight-forward... It supports overlays, which means
> > only one thing is ultimately visible for a c/p-v.
> 
> I know.
> 
> >
> > --
> > Ciaran McCreesh
> >
> 
> I am wondering if enabling @overlay postfix support could be just restricted to command line arguments, at least for the beginning.

And then it's a pm thing. So the person you want to talk about it is
zmedico.

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[lxnay]

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



On Sun, May 24, 2009 at 9:28 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
> Am Sonntag, den 24.05.2009, 20:04 +0200 schrieb lxnay@sabayonlinux.org:
>
> And then it's a pm thing. So the person you want to talk about it is
> zmedico.

And zmedico told me to start discussing here.

>
> --
> Tiziano Müller
> Gentoo Linux Developer, Council Member
> Areas of responsibility:
>  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
> E-Mail   : dev-zero@gentoo.org
> GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30
>



-- 
Fabio Erculiani


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Alex Legler]

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

On So, 2009-05-24 at 20:04 +0200, lxnay@sabayonlinux.org wrote:
> [...]
> >> app-admin/equo (sabayon overlay -- Entropy Framework client) supports
> >> the postfix "@repository" to let users force the installation of a
> >> package from a specific repository.
> >
> > @ is used by Portage for sets. Paludis has been using ::repo for repo
> > dependencies for years. Why not go with the established syntax?
> 
> I wrote "postfix" not "prefix". Sets use "@" prefix.

Your @ is still a prefix for the repository name.

For usability's sake, please don't do this. I can imagine users getting
confused over the different meanings of the @ sign.

I do not want to trigger a discussion like the one PHP had when choosing
namespace separators, but we got the "::" established in Paludis and
Paludis is used by way more Gentoo people than equo.

So it only seems logical to me to use the wider-known and at the same
time ambiguity-free "operator".

Alex

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

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[lxnay]

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



On Mon, May 25, 2009 at 3:43 PM, Alex Legler <a3li@gentoo.org> wrote:
> On So, 2009-05-24 at 20:04 +0200, lxnay@sabayonlinux.org wrote:
>> [...]
>> >> app-admin/equo (sabayon overlay -- Entropy Framework client) supports
>> >> the postfix "@repository" to let users force the installation of a
>> >> package from a specific repository.
>> >
>> > @ is used by Portage for sets. Paludis has been using ::repo for repo
>> > dependencies for years. Why not go with the established syntax?
>>
>> I wrote "postfix" not "prefix". Sets use "@" prefix.
>
> Your @ is still a prefix for the repository name.

Yeah but "emerge @overlay" would be obviously illegal. So your argument is a bit pointless ;)

>
> For usability's sake, please don't do this. I can imagine users getting
> confused over the different meanings of the @ sign.
>
> I do not want to trigger a discussion like the one PHP had when choosing
> namespace separators, but we got the "::" established in Paludis and
> Paludis is used by way more Gentoo people than equo.

"::" C++/PHP/whatever separator has nothing to do with the purpose of "@overlay".
Paludis is not a Gentoo project and doesn't follow Gentoo features validation rules.
So is Entropy. If Paludis has its own syntax it doesn't automatically mean that Gentoo Portage *has to* follow it.
I prefer a more democratic way => discussing here.

>
> So it only seems logical to me to use the wider-known and at the same
> time ambiguity-free "operator".
>
> Alex
>



-- 
Fabio Erculiani


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[AllenJB]

lxnay@sabayonlinux.org wrote:
> 
> 
> On Mon, May 25, 2009 at 3:43 PM, Alex Legler <a3li@gentoo.org> wrote:
>> On So, 2009-05-24 at 20:04 +0200, lxnay@sabayonlinux.org wrote:
>>> [...]
>>> >> app-admin/equo (sabayon overlay -- Entropy Framework client) supports
>>> >> the postfix "@repository" to let users force the installation of a
>>> >> package from a specific repository.
>>> >
>>> > @ is used by Portage for sets. Paludis has been using ::repo for repo
>>> > dependencies for years. Why not go with the established syntax?
>>>
>>> I wrote "postfix" not "prefix". Sets use "@" prefix.
>>
>> Your @ is still a prefix for the repository name.
> 
> Yeah but "emerge @overlay" would be obviously illegal. So your argument 
> is a bit pointless ;)
> 
>>
>> For usability's sake, please don't do this. I can imagine users getting
>> confused over the different meanings of the @ sign.
>>
>> I do not want to trigger a discussion like the one PHP had when choosing
>> namespace separators, but we got the "::" established in Paludis and
>> Paludis is used by way more Gentoo people than equo.
> 
> "::" C++/PHP/whatever separator has nothing to do with the purpose of 
> "@overlay".
Personally I think the PHP namespace syntax issue is a very good 
analogy. There's an established syntax, even if it's not a written 
standard, already used in a very similar situation, and that should be 
taken into account.

> Paludis is not a Gentoo project and doesn't follow Gentoo features 
> validation rules.
> So is Entropy. If Paludis has its own syntax it doesn't automatically 
> mean that Gentoo Portage *has to* follow it.
> I prefer a more democratic way => discussing here.

As far as I can see, a discussion is happening. You started a discussion 
here and others mentioned that there is a specific syntax already used 
for this by a very similar application.

You appear to be the only one who's arguing against that syntax. As a 
user, I have to agree that using @ for multiple purposes, even if it 
can't be applied to the same purposes in different locations, is 
potentially confusing, even if not just plain silly.

As a side note, I think I've read somewhere that it may in the future be 
possible to specify sets in package.* (which I assume would be done 
using the @set-name syntax), but can't remember where off-hand. This may 
have just been a suggestion, but if it ever is implemented, it would 
surely add to the confusion.

AllenJB

> 
>>
>> So it only seems logical to me to use the wider-known and at the same
>> time ambiguity-free "operator".
>>
>> Alex

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Dale]

AllenJB wrote:
>
> As a side note, I think I've read somewhere that it may in the future
> be possible to specify sets in package.* (which I assume would be done
> using the @set-name syntax), but can't remember where off-hand. This
> may have just been a suggestion, but if it ever is implemented, it
> would surely add to the confusion.
>
> AllenJB

Is this the location you are talking about? 

root@smoker / # ls -al /etc/portage/sets/
total 21
drwxrwsr-x 2 root portage  128 Apr 22 19:04 .
drwxr-xr-x 7 root portage  536 May 21 00:53 ..
-rw-r--r-- 1 root portage 1353 Feb 23 04:49 dk-kde
-rw-r--r-- 1 root portage 6453 Apr 22 19:04 dk-kde-full
-rw-r--r-- 1 root portage 6795 Apr 17 21:59 rebuild
root@smoker / #

I already have a couple of those in use with Portage 2.2_rc33.  If you
are talking about something else, please ignore.

Dale

:-)  :-) 

[gentoo-dev] Re: RFC:sys-apps/portage @overlay atoms postfix support

[Steven J Long]

AllenJB wrote:

> lxnay@sabayonlinux.org wrote:
>> 
>> 
>> On Mon, May 25, 2009 at 3:43 PM, Alex Legler <a3li@gentoo.org> wrote:
>>> For usability's sake, please don't do this. I can imagine users getting
>>> confused over the different meanings of the @ sign.
>>>
> Personally I think the PHP namespace syntax issue is a very good
> analogy. There's an established syntax, even if it's not a written
> standard, already used in a very similar situation, and that should be
> taken into account.
>
Why can't we just use the cleanest syntax, irrespective of what external
projects do? Surely that's the point of standing back and facilitating their
use of the tree; so that we can decide what and *how* would be useful for
all Gentoo users.
 
> You appear to be the only one who's arguing against that syntax. As a
> user, I have to agree that using @ for multiple purposes, even if it
> can't be applied to the same purposes in different locations, is
> potentially confusing, even if not just plain silly.
>
> As a side note, I think I've read somewhere that it may in the future be
> possible to specify sets in package.* (which I assume would be done
> using the @set-name syntax), but can't remember where off-hand. This may
> have just been a suggestion, but if it ever is implemented, it would
> surely add to the confusion.
> 
I don't see the ambiguity; it's perfectly unambiguous to a lexer, and
immediately apparent to a user too. If it's got an @ at the beginning, it's
a set name. If an atom has an @ after the package name (and possibly version
etc) it means "from that overlay."

Note that I think we can use the syntax elsewhere, without ambiguity.

Surely it would be best simply to ask end-users which of a few variants
they'd find easiest to work with? Or indeed for their suggestions; after
all, they spend a lot more time engaging with the cli/config files than we
do.

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

[gentoo-dev] Re: RFC:sys-apps/portage @overlay atoms postfix support

[Duncan]

Steven J Long <slong@rathaus.eclipse.co.uk> posted
2115173.05GpC6T6bt@news.friendly-coders.info, excerpted below, on  Tue, 02
Jun 2009 09:18:54 +0100:

> Surely it would be best simply to ask end-users which of a few variants
> they'd find easiest to work with? Or indeed for their suggestions; after
> all, they spend a lot more time engaging with the cli/config files than
> we do.

For this end-user, @ means set.  Using it at a location other than the 
beginning for something else is possible and I'd adapt, but it /is/ 
confusing.

:: lacks that confusion.  It does have the additional complication of 
needing quoted or escaped in the shell, but users are supposed to do a
--pretend anyway, and after it doesn't output what's expected, a user of 
any shell experience at all should conclude with little delay that it 
/could/ be the escaping even if they aren't sure, and a quick suitably 
escaped trial will confirm it.

So either proposed solution has its caveat that users will ultimately 
need to learn to deal with, but I still prefer the unambiguity of ::.

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

Re: [gentoo-dev] Re: RFC:sys-apps/portage @overlay atoms postfix support

[Piotr Jaroszyński]

2009/6/2 Duncan <1i5t5.duncan@cox.net>:
> :: lacks that confusion.  It does have the additional complication of
> needing quoted or escaped in the shell, but users are supposed to do a
> --pretend anyway, and after it doesn't output what's expected, a user of
> any shell experience at all should conclude with little delay that it
> /could/ be the escaping even if they aren't sure, and a quick suitably
> escaped trial will confirm it.

Where/when does :: need escaping?

-- 
Best Regards,
Piotr Jaroszyński

[gentoo-dev] Re: RFC:sys-apps/portage @overlay atoms postfix support

[Duncan]

Piotr Jaroszyński <peper@gentoo.org> posted
d77765540906031651q55f93c07t78beb1191f3bf9b0@mail.gmail.com, excerpted
below, on  Thu, 04 Jun 2009 01:51:01 +0200:

> Where/when does :: need escaping?

I'm not sure about this particular usage case as I haven't quite wrapped 
my mind around how to test it without it actually being at least stubbed 
into portage to test (not that I've spent too long trying, but given your 
question, a few seconds contemplation lead me to the conclusion that 
there was more to it than I might have than I thought), but bash 
completion at lest wants escaped colons in paths (and tab-completes them 
escaped with \), for instance, and shell scripts often use colons as 
field separators for filenames or paths as well, due to the relatively 
low frequency of use.

It was the shell path stuff that I was thinking about when I cautioned 
about escapes.  Maybe that doesn't apply in usage such as users would be 
using with portage?

To confirm the above shell (well, shell completion) issues, I just 
created a dir ~/::test.  Trying to tab-complete just a single colon 
produced unexpected results (either a listing of the entire parent dir, 
or :\:\:test, an extra colon, which naturally then failed to work 
as :::test didn't exist, depending on what I was tab-completing), while 
tab-completing a backslash escaped colon produced the desired results.

Similar results if I tried to tab-complete a double-colon.  When I tried 
to remove the ::test dir.  rm -ri ::<tab> resulted in a completion 
of ::::test/, which of course gave me an error saying it couldn't 
find ::::test, but rm -ri \:<tab> completed correctly, and the rm 
succeeded.

A retest typing in the entire name, ::test (thus NOT using tab-
completion), however, worked correctly, so perhaps it's more accurate to 
say it's a bash-completion bug, while the shell itself works fine.  Given 
that, we'd probably be OK at least until the gentoo-bashcomp update, and 
perhaps it could be worked around there.

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

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Robert Buchholz]

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

On Monday 25 May 2009, lxnay@sabayonlinux.org wrote:
> On Mon, May 25, 2009 at 3:43 PM, Alex Legler <a3li@gentoo.org> wrote:
> > On So, 2009-05-24 at 20:04 +0200, lxnay@sabayonlinux.org wrote:
> >> [...]
> >>
> >> >> app-admin/equo (sabayon overlay -- Entropy Framework client)
> >> >> supports the postfix "@repository" to let users force the
> >> >> installation of a package from a specific repository.
> >> >
> >> > @ is used by Portage for sets. Paludis has been using ::repo for
> >> > repo dependencies for years. Why not go with the established
> >> > syntax?
> >>
> >> I wrote "postfix" not "prefix". Sets use "@" prefix.
> >
> > Your @ is still a prefix for the repository name.
>
> Yeah but "emerge @overlay" would be obviously illegal. So your
> argument is a bit pointless ;)

# emerge --update lsof @system

versus

# emerge --update lsof@system

would have completely different meanings. This is what I would dislike 
about the '@' character. I'm ok with :: though.

If we use repo_name as the overlay identifier, we must rethink how 
layman-global.txt is currently handled. Many overlays in there have 
that file missing, and some have different identifiers than what layman 
displays as their name.

Is this specifier stored and considered on future dependency
calculations (e.g. updates, dependencies of other ebuilds on the 
package that was installed via @overlay)? Where is it stored, how is it 
displayed to the user in emerge/eix output?


Robert

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

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Ben de Groot]

Robert Buchholz wrote:
> # emerge --update lsof @system
> 
> versus
> 
> # emerge --update lsof@system
> 
> would have completely different meanings. This is what I would dislike 
> about the '@' character. I'm ok with :: though.

I agree the :: looks like the better option here.

> If we use repo_name as the overlay identifier, we must rethink how 
> layman-global.txt is currently handled. Many overlays in there have 
> that file missing, and some have different identifiers than what layman 
> displays as their name.

I think layman should simply start to use the repo_name as identifier.
That should result in less confusion, I'd think. Overlays that miss the
repo_name file are broken and should be fixed, and should be ignored
until they are.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
______________________________________________________

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Robert Buchholz]

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

On Monday 25 May 2009, Ben de Groot wrote:
> Robert Buchholz wrote:
> > If we use repo_name as the overlay identifier, we must rethink how
> > layman-global.txt is currently handled. Many overlays in there have
> > that file missing, and some have different identifiers than what
> > layman displays as their name.
>
> I think layman should simply start to use the repo_name as
> identifier. That should result in less confusion, I'd think. Overlays
> that miss the repo_name file are broken and should be fixed, and
> should be ignored until they are.

Unfortunately, that value is not known until the repository is checked 
out. Doing that on every "list" operation would be too much overhead. 
We do need a script to verify the layman list, nevertheless.
(Don't look at me for this! :-)


Robert

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

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[lxnay]

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

So, "::" vs "@" apart, is it something that is worth looking and implementing in future EAPIs?

-- 
Fabio Erculiani


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 270 bytes --]

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Ciaran McCreesh]

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

On Tue, 26 May 2009 10:13:51 +0200 (CEST)
lxnay@sabayonlinux.org wrote:
> So, "::" vs "@" apart, is it something that is worth looking and
> implementing in future EAPIs?

Isn't it just a user issue, not one we want used anywhere where EAPI
rules are in effect?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Nirbheek Chauhan]

On Tue, May 26, 2009 at 6:50 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 26 May 2009 10:13:51 +0200 (CEST)
> lxnay@sabayonlinux.org wrote:
>> So, "::" vs "@" apart, is it something that is worth looking and
>> implementing in future EAPIs?
>
> Isn't it just a user issue, not one we want used anywhere where EAPI
> rules are in effect?
>

Indeed. Since the consensus is for using it as part of the UI, you
don't need to wait for EAPI=4, you (lxnay) can start writing patches
for portage (regardless of which operator is used) to recognize such
atoms on the command line.


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Petteri Räty]

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

lxnay@sabayonlinux.org wrote:
> So, "::" vs "@" apart, is it something that is worth looking and
> implementing in future EAPIs?
> 

I don't see the main tree referring to other repositories any time soon
so this is not a pressing issue. But as said earlier this makes sense
for /etc/portage stuff so there going forward seems prudent. I suggest
using "::" as it's more established in these circles.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Nirbheek Chauhan]

On Sun, May 24, 2009 at 10:34 PM,  <lxnay@sabayonlinux.org> wrote:
> Adding "@overlay" atoms/deps postfix support could really make life
> easier, especially because forcing specific atoms in *DEPEND hoping
> that these will be always pulled in from the same overlay is not
> something reliable, as you already know.
>
> Examples:
>
> app-foo/foo@overlay
> app-foo/foo:2@overlay
> foo:2@overlay
> foo@overlay
>
> Comments are welcome, flames are not.

Won't this just lead to dependency hell? With horrible dependencies
between different overlays?

The current system of "overlays" being restrictive is (IMO) beneficial
in the long-term because it forces people to move stuff to the main
tree instead of going the lazy way and putting inter-overlay
dependencies.

If the concept of "overlay" is taken as "feature overlays", then
dependencies should not go beyond the main tree + the overlay itself.


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Ciaran McCreesh]

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

On Sun, 24 May 2009 22:50:45 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> Won't this just lead to dependency hell? With horrible dependencies
> between different overlays?

It's primarily a user feature. It's not a good way of solving most
inter-repository dependency issues.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Nirbheek Chauhan]

On Sun, May 24, 2009 at 10:58 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 24 May 2009 22:50:45 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>> Won't this just lead to dependency hell? With horrible dependencies
>> between different overlays?
>
> It's primarily a user feature. It's not a good way of solving most
> inter-repository dependency issues.
>

If that's the case (usage being command-line use), then I'm all for
it. But not in *DEPEND.


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Ben de Groot]

Nirbheek Chauhan wrote:
> On Sun, May 24, 2009 at 10:58 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Sun, 24 May 2009 22:50:45 +0530
>> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>>> Won't this just lead to dependency hell? With horrible dependencies
>>> between different overlays?
>> It's primarily a user feature. It's not a good way of solving most
>> inter-repository dependency issues.
> 
> If that's the case (usage being command-line use), then I'm all for
> it. But not in *DEPEND.
> 
I'm also very much for it, especially for use in /etc/portage, to be
able to mask/unmask a version from a specific overlay.

-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
______________________________________________________

Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support

[Josh Saddler]

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

lxnay@sabayonlinux.org wrote:
> Adding "@overlay" atoms/deps postfix support could really make life
> easier, especially because forcing specific atoms in *DEPEND hoping
> that these will be always pulled in from the same overlay is not
> something reliable, as you already know.

No. This is a terrible idea. The solution is to *fix the overlays*, not
force the user to intervene and fix things himself.

Conflicting overlay issues turn up on the Gentoo forums (check
Unsupported Software), and in pretty much all cases, once the
maintainer(s) of the overlay(s) are contacted about the issue, the
overlays are quickly fixed so that the next update sorts out the user's
tree.

Users should *not *have to take steps to fix overlay blocks and breaks
ahead of time; that should be the overlay maintainer's job, not the poor
end user.

> Comments are welcome, flames are not.

On that note, I'd like to offer a friendly word of caution, in the
interests of us all talking together and working through the ideas
presented in your threads.

In your last visit to our mailing list
(http://thread.gmane.org/gmane.linux.gentoo.devel/55180), you stated
that you'd like to make some sweeping changes to Gentoo, then you
started telling the developers why they all sucked ahead of time for not
implementing said ideas. And then you kept telling developers that they
sucked throughout the rest of the replies.

You expressed unwillingness to work with Gentoo developers through our
admittedly long recruitment process, instead wanting to push your
changes to our tree directly.

There wasn't very much accomplished on either side at the end of that
debacle, except some hurt feelings.

It seems that the discussions you're having in the binary packages and
overlay threads are already heading the same direction, and I for one
don't want that to happen. Telling people they're not allowed to express
disagreement is counterproductive.[1][2]

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/61555/focus=61568
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/61530/focus=61560

So, folks, just take it easy. We don't have to accept every suggestion
offered to the list, nor do we have to reject it out of hand.

Thanks.


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