FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 07-03-2012, 03:44 AM
Kent Fredric
 
Default ?DEPEND

Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
but not more than one of".

However, to my knowledge, we don't have such for ebuilds.

Sure, there are ways of implementing this in ebuilds without this
notation, but they're a bit messy.

For instance, we seem to find the need for something like this in perl
virtuals,

|| ( =dev-lang/perl-$A =perl-core/foo-$B )

However, this current form has its limitations:

1. If =perl-core/foo-$B was previously installed, satisfying the
condition, and =dev-lang/perl-$A becomes installed, perl-core/foo-$B
then gets ignored, but its still left installed, and not cleaned.

2. Due to the nature of how perl works, any version installed from
perl-core/ will "shadow" the version installed by dev-lang/perl , so
that, despite the virtual being satisfied, the version of the code you
get is unsatisfactory from time to time. ie:

dev-lang/perl-5.10 might provide 'quux-1.2.3' , as will
perl-core/quux-1.2.3

If you were previously on perl-5.8 , ( which only shipped quux-1.1 ) ,
and had installed =virtual/perl-quux-1.2.2 , you would have to
install =perl-core/quux-1.2.2 to get "quux-1.2.2"

Along comes 5.10, and quux-1.2.3 , so we release virtual/perl-quux-1.2.3

|| ( =dev-lang/perl-5.10 =perl-core/quux-1.2.3 )

^^ this does what we want most of the time, if you can install
perl-5.10, just do that to get quux 1.2.3, otherwise, install
quux-1.2.3 from perl-core .

However, in the above case, what happens is virtual/perl-quuux-1.2.3
is installed, which is satisfied by '=dev-lang/perl-5.10" , and
portage is happy with that.

And then you do 'perl -e 'use quux 1.2.3' # and it barfs saying 1.2.2
is still installed, which it is, because perl-core/quux-1.2.2 is still
installed, overshadowing the more recent one provided by dev-lang/perl

Ideally, what we want here is ^^( ), or something like it, so that if
the earlier part is satisfied, latter parts are then removed.

You *can* represent the same logic with other mechanisms, but its much
much more complex to do so.

|| (
(
=dev-lang/perl-5.10
!<perl-core/quux-1.2.3
!>perl-core/quux-1.2.3
)
(
!dev-lang/perl-5.10
=perl-core/quux-1.2.3
)
)

And I *think* that will do the right thing, I really have no idea.

The other approach of course is to make the blockers happen in
dev-lang/perl and perl-core/quux , but this has its own problems.

For instance, =dev-lang/perl *cannot* specify which versions of
perl-core/quux can and cannot be installed. Because its not *perl*
that is trying to define what version is installed, but the virtual.

And perl-core/quux can't really block perl , because the whole point
of perl-core/quux is to be installed on perls other than the ones it
was shipped with.


^^( ) seems to nicely help solve this problem, and it seems like an
oversight that we have OR , AND , and NOT dependency rules, but not
XOR.

P.S. Blame Patrick for this message.

--
Kent

perl -e "print substr( "edrgmaM SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
 
Old 07-03-2012, 03:44 AM
Kent Fredric
 
Default ?DEPEND

Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
but not more than one of".

However, to my knowledge, we don't have such for ebuilds.

Sure, there are ways of implementing this in ebuilds without this
notation, but they're a bit messy.

For instance, we seem to find the need for something like this in perl
virtuals,

|| ( =dev-lang/perl-$A =perl-core/foo-$B )

However, this current form has its limitations:

1. If =perl-core/foo-$B was previously installed, satisfying the
condition, and =dev-lang/perl-$A becomes installed, perl-core/foo-$B
then gets ignored, but its still left installed, and not cleaned.

2. Due to the nature of how perl works, any version installed from
perl-core/ will "shadow" the version installed by dev-lang/perl , so
that, despite the virtual being satisfied, the version of the code you
get is unsatisfactory from time to time. ie:

dev-lang/perl-5.10 might provide 'quux-1.2.3' , as will
perl-core/quux-1.2.3

If you were previously on perl-5.8 , ( which only shipped quux-1.1 ) ,
and had installed =virtual/perl-quux-1.2.2 , you would have to
install =perl-core/quux-1.2.2 to get "quux-1.2.2"

Along comes 5.10, and quux-1.2.3 , so we release virtual/perl-quux-1.2.3

|| ( =dev-lang/perl-5.10 =perl-core/quux-1.2.3 )

^^ this does what we want most of the time, if you can install
perl-5.10, just do that to get quux 1.2.3, otherwise, install
quux-1.2.3 from perl-core .

However, in the above case, what happens is virtual/perl-quuux-1.2.3
is installed, which is satisfied by '=dev-lang/perl-5.10" , and
portage is happy with that.

And then you do 'perl -e 'use quux 1.2.3' # and it barfs saying 1.2.2
is still installed, which it is, because perl-core/quux-1.2.2 is still
installed, overshadowing the more recent one provided by dev-lang/perl

Ideally, what we want here is ^^( ), or something like it, so that if
the earlier part is satisfied, latter parts are then removed.

You *can* represent the same logic with other mechanisms, but its much
much more complex to do so.

|| (
(
=dev-lang/perl-5.10
!<perl-core/quux-1.2.3
!>perl-core/quux-1.2.3
)
(
!dev-lang/perl-5.10
=perl-core/quux-1.2.3
)
)

And I *think* that will do the right thing, I really have no idea.

The other approach of course is to make the blockers happen in
dev-lang/perl and perl-core/quux , but this has its own problems.

For instance, =dev-lang/perl *cannot* specify which versions of
perl-core/quux can and cannot be installed. Because its not *perl*
that is trying to define what version is installed, but the virtual.

And perl-core/quux can't really block perl , because the whole point
of perl-core/quux is to be installed on perls other than the ones it
was shipped with.


^^( ) seems to nicely help solve this problem, and it seems like an
oversight that we have OR , AND , and NOT dependency rules, but not
XOR.

P.S. Blame Patrick for this message.

--
Kent

perl -e "print substr( "edrgmaM SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
 
Old 07-03-2012, 07:08 AM
Ciaran McCreesh
 
Default ?DEPEND

On Tue, 3 Jul 2012 15:44:04 +1200
Kent Fredric <kentfredric@gmail.com> wrote:
> Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
> but not more than one of".

A user has a and b installed. c depends upon ^^ ( a b ). The user tries
to install c. What happens?

--
Ciaran McCreesh
 
Old 07-03-2012, 08:24 AM
Michał Górny
 
Default ?DEPEND

On Tue, 3 Jul 2012 15:44:04 +1200
Kent Fredric <kentfredric@gmail.com> wrote:

> Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
> but not more than one of".
>
> However, to my knowledge, we don't have such for ebuilds.
>
> Sure, there are ways of implementing this in ebuilds without this
> notation, but they're a bit messy.
>
> For instance, we seem to find the need for something like this in perl
> virtuals,
>
> || ( =dev-lang/perl-$A =perl-core/foo-$B )
>
> However, this current form has its limitations:
>
> 1. If =perl-core/foo-$B was previously installed, satisfying the
> condition, and =dev-lang/perl-$A becomes installed, perl-core/foo-$B
> then gets ignored, but its still left installed, and not cleaned.

--depclean?

> 2. Due to the nature of how perl works, any version installed from
> perl-core/ will "shadow" the version installed by dev-lang/perl , so
> that, despite the virtual being satisfied, the version of the code you
> get is unsatisfactory from time to time. ie:
>
> dev-lang/perl-5.10 might provide 'quux-1.2.3' , as will
> perl-core/quux-1.2.3
>
> If you were previously on perl-5.8 , ( which only shipped quux-1.1 ) ,
> and had installed =virtual/perl-quux-1.2.2 , you would have to
> install =perl-core/quux-1.2.2 to get "quux-1.2.2"
>
> Along comes 5.10, and quux-1.2.3 , so we release
> virtual/perl-quux-1.2.3
>
> || ( =dev-lang/perl-5.10 =perl-core/quux-1.2.3 )
>
> ^^ this does what we want most of the time, if you can install
> perl-5.10, just do that to get quux 1.2.3, otherwise, install
> quux-1.2.3 from perl-core .
>
> However, in the above case, what happens is virtual/perl-quuux-1.2.3
> is installed, which is satisfied by '=dev-lang/perl-5.10" , and
> portage is happy with that.

Doesn't perl-cleaner handle perl upgrades for this? And the tested
ABI_SLOTs should help with that too.

> And then you do 'perl -e 'use quux 1.2.3' # and it barfs saying 1.2.2
> is still installed, which it is, because perl-core/quux-1.2.2 is still
> installed, overshadowing the more recent one provided by dev-lang/perl
>
> Ideally, what we want here is ^^( ), or something like it, so that if
> the earlier part is satisfied, latter parts are then removed.
>
> You *can* represent the same logic with other mechanisms, but its much
> much more complex to do so.
>
> || (
> (
> =dev-lang/perl-5.10
> !<perl-core/quux-1.2.3
> !>perl-core/quux-1.2.3
> )
> (
> !dev-lang/perl-5.10
> =perl-core/quux-1.2.3
> )
> )
>
> And I *think* that will do the right thing, I really have no idea.

This is a really fragile approach, and is mostly a workaround
to the real issue. You want to say «I need *only* one of my
dependencies satisfied» while you actually get «if I'm installed, then
let every my dependency in those blocks actually block each other».

That's just impossible to achieve. Think of ^^ ( foo bar ). When
the package gets installed, foo is installed and bar is not. Then you
want to emerge bar. What should happen?

a) you want portage to refuse to do that. Why would it? AFAIU this
would no longer be a problem actually.

b) you want portage to do that. But you just forced it unmerge it? It
will install the previously made binary package and it's back...

c) you want portage to unmerge foo because the dep will now be
satisfied by bar. Wait... unmerge perl?

> The other approach of course is to make the blockers happen in
> dev-lang/perl and perl-core/quux , but this has its own problems.
>
> For instance, =dev-lang/perl *cannot* specify which versions of
> perl-core/quux can and cannot be installed. Because its not *perl*
> that is trying to define what version is installed, but the virtual.
>
> And perl-core/quux can't really block perl , because the whole point
> of perl-core/quux is to be installed on perls other than the ones it
> was shipped with.
>
>
> ^^( ) seems to nicely help solve this problem, and it seems like an
> oversight that we have OR , AND , and NOT dependency rules, but not
> XOR.
>
> P.S. Blame Patrick for this message.
>



--
Best regards,
Michał Górny
 
Old 07-03-2012, 08:24 AM
Kent Fredric
 
Default ?DEPEND

On 3 July 2012 19:08, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 3 Jul 2012 15:44:04 +1200
> Kent Fredric <kentfredric@gmail.com> wrote:
>> Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
>> but not more than one of".
>
> A user has a and b installed. c depends upon ^^ ( a b ). The user tries
> to install c. What happens?

I'd expect that the user would have to remove one of ( a b ), the
natural choice would be to remove b, a taking precedence.

> --
> Ciaran McCreesh



--
Kent

perl -e "print substr( "edrgmaM SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
 
Old 07-03-2012, 05:56 PM
Ciaran McCreesh
 
Default ?DEPEND

On Tue, 3 Jul 2012 20:24:43 +1200
Kent Fredric <kentfredric@gmail.com> wrote:
> On 3 July 2012 19:08, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 3 Jul 2012 15:44:04 +1200
> > Kent Fredric <kentfredric@gmail.com> wrote:
> >> Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one
> >> of, but not more than one of".
> >
> > A user has a and b installed. c depends upon ^^ ( a b ). The user
> > tries to install c. What happens?
>
> I'd expect that the user would have to remove one of ( a b ), the
> natural choice would be to remove b, a taking precedence.

But whether or not a and b can be installed together sounds an awful
lot like a property of a and b, not of c.

--
Ciaran McCreesh
 
Old 07-03-2012, 06:20 PM
Kent Fredric
 
Default ?DEPEND

On 4 July 2012 05:56, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
> But whether or not a and b can be installed together sounds an awful
> lot like a property of a and b, not of c.

Its just when C is really something abstract, ( a virtual ) provided
by both possibly a & b, and b doesn't know a even exists till after
the fact, and vice versa, that solving the problem in a & b becomes
messy.

If you solve it in one side ( in my example, perl-core ) you end up
having a lot of weird conditional logic trying to work out src_uri,
dependencies, and whether or not to actually do anything.

If you solve it on the other side ( in my example, dev-lang/perl ) ,
you end up having perl specify what versions of the abstract notion
can and cannot be installed, instead of the abstract notion specifying
what is *needed* and there is a resolution required to provide that.

if a package specifies : " =virtual-Foo-5.0 " , that means "I want the
Foo.pm version 5.0, I don't care how you get it, get it".

Only the virtual can convey *how* to get that.

ie: perhaps =virtual-Foo-5.0 can only be satisfied by installing
dev-lang/perl-5.10 ( its not in any other Perl, or on CPAN )
or perhaps =virtual-Foo-5.0 can be satisfied by installing
perl-core/Foo-5.0 on any perl

And there are dozens of packages that ask for "Foo-5.0" , and the only
other altnative we had before we had the virtual/perl-* family, was to
ignore the dependency entirely and hope for the best, or depend on a
minimum perl we know had it ( which is a different minimum perl than
what upstream specifies, because upstream assume you can install
things from CPAN , and/or depend on the nearest match that *is*
available via perl-core/* , risking the possibility that it will
install a version from CPAN that is to become outdated by a future
perl release, but you'll keep installed anyway, giving the shadow
effect again.

Essentially, the problem at the bottom of this, is Perl Modules depend
on each other by components in distributions ( the modules ), not the
distributions themselves. Its merely convention that distributions
have a name and version that is the same of a module also contained in
that distribution.

--
Kent

perl -e "print substr( "edrgmaM SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz
 

Thread Tools




All times are GMT. The time now is 05:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org