Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND
On Tue, 3 Jul 2012 15:44:04 +1200 Kent Fredric kentfred...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
El lun, 02-07-2012 a las 13:45 -0700, Zac Medico escribió: On 07/02/2012 01:36 PM, viv...@gmail.com wrote: Il 02/07/2012 22:01, Zac Medico ha scritto: On 07/02/2012 12:48 PM, Pacho Ramos wrote: El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió: Hi, In case you aren't familiar with FEATURES=userpriv, here's the description from the make.conf(5) man page: Allow portage to drop root privileges and compile packages as portage:portage without a sandbox (unless usersandbox is also used). The rationale for having the separate usersandbox setting, to enable use of sys-apps/sandbox, is that people who enable userpriv sometimes prefer to have sandbox disabled in order to slightly improve performance. However, I would recommend to enable usersandbox by default, for the purpose of logging sandbox violations. Note that ebuilds can set RESTRICT=userpriv if they require superuser privileges during any of the src_* phases that userpriv affects. I've been using FEATURES=userpriv usersandbox for years, and I don't remember experiencing any problems because of it, so I think that it would be reasonable to have it enabled by default. Objections? Looks like non important problems arised and, then, these could probably be enabled by default, no? :) I'm not sure about the best way to handle migration for directories inside $DISTDIR that are used by live ebuilds, since src_unpack will run with different privileges when userpriv is enabled. tell the user to chown/remove the files/directories if and when needed, How should we tell them? Elog message, news item, or both? unless there is a very good reason (try) to automate it. I guess something like this might work in pkg_postinst of the portage ebuild: find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R portage:portage I would only trigger something like this once, when upgrading from a version that doesn't have userpriv enabled by default. This looks reasonable, I think signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
On Mon, 02 Jul 2012 13:45:26 -0700
Zac Medico zmed...@gentoo.org wrote:
On 07/02/2012 01:36 PM, viv...@gmail.com wrote:
Il 02/07/2012 22:01, Zac Medico ha scritto:
On 07/02/2012 12:48 PM, Pacho Ramos wrote:
El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
Hi,
In case you aren't familiar with FEATURES=userpriv, here's the
description from the make.conf(5) man page:
Allow portage to drop root privileges and compile packages as
portage:portage without a sandbox (unless usersandbox is also
used).
The rationale for having the separate usersandbox setting, to
enable use of sys-apps/sandbox, is that people who enable
userpriv sometimes prefer to have sandbox disabled in order to
slightly improve performance. However, I would recommend to
enable usersandbox by default, for the purpose of logging
sandbox violations.
Note that ebuilds can set RESTRICT=userpriv if they require
superuser privileges during any of the src_* phases that
userpriv affects.
I've been using FEATURES=userpriv usersandbox for years, and I
don't remember experiencing any problems because of it, so I
think that it would be reasonable to have it enabled by default.
Objections?
Looks like non important problems arised and, then, these could
probably be enabled by default, no? :)
I'm not sure about the best way to handle migration for directories
inside $DISTDIR that are used by live ebuilds, since src_unpack
will run with different privileges when userpriv is enabled.
tell the user to chown/remove the files/directories if and when
needed,
How should we tell them? Elog message, news item, or both?
I think this deserves a news item anyway.
unless there is a very good reason (try) to automate it.
I guess something like this might work in pkg_postinst of the portage
ebuild:
find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R
portage:portage
find $DISTDIR -maxdepth 1 -type d -uid 0 -exec \
chown -R portage:portage {} +
I would only trigger something like this once, when upgrading from a
version that doesn't have userpriv enabled by default.
This will work only for users who actually keep those in DISTDIR. Some
of them actually redefine E*_STORE_DIR to a more sane location. But
that's probably irrelevant.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
Il 02/07/2012 22:45, Zac Medico ha scritto: On 07/02/2012 01:36 PM, viv...@gmail.com wrote: Il 02/07/2012 22:01, Zac Medico ha scritto: On 07/02/2012 12:48 PM, Pacho Ramos wrote: El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió: Hi, In case you aren't familiar with FEATURES=userpriv, here's the description from the make.conf(5) man page: Allow portage to drop root privileges and compile packages as portage:portage without a sandbox (unless usersandbox is also used). The rationale for having the separate usersandbox setting, to enable use of sys-apps/sandbox, is that people who enable userpriv sometimes prefer to have sandbox disabled in order to slightly improve performance. However, I would recommend to enable usersandbox by default, for the purpose of logging sandbox violations. Note that ebuilds can set RESTRICT=userpriv if they require superuser privileges during any of the src_* phases that userpriv affects. I've been using FEATURES=userpriv usersandbox for years, and I don't remember experiencing any problems because of it, so I think that it would be reasonable to have it enabled by default. Objections? Looks like non important problems arised and, then, these could probably be enabled by default, no? :) I'm not sure about the best way to handle migration for directories inside $DISTDIR that are used by live ebuilds, since src_unpack will run with different privileges when userpriv is enabled. tell the user to chown/remove the files/directories if and when needed, How should we tell them? Elog message, news item, or both? both seem reasonable, additionally emerge will and should fail when it meet a incorrect owned directory, the most sensitive place where to output the message is exactly there if possible. Failed to update $DIR, check permission and/or correctness, as a last resort remove it something like this, written by someone who speak english. unless there is a very good reason (try) to automate it. I guess something like this might work in pkg_postinst of the portage ebuild: find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R portage:portage I would only trigger something like this once, when upgrading from a version that doesn't have userpriv enabled by default. ba, I've totally inverted the logic, it was meant do _not_ automate it, even if the chown work flawlessy it become additional cruft that will be forever with us. thanks, Francesco
Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND
On Tue, 3 Jul 2012 15:44:04 +1200 Kent Fredric kentfred...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND
On 3 July 2012 19:08, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 3 Jul 2012 15:44:04 +1200 Kent Fredric kentfred...@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
Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On 3 July 2012 20:24, Michał Górny mgo...@gentoo.org wrote:
--depclean?
eix Module-Metadata
[I] perl-core/Module-Metadata
Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9---
not unmasked by --autounmask
Installed versions: 1.0.6(15:59:00 06/26/12)
Homepage:http://search.cpan.org/dist/Module-Metadata/
Description: Gather package and POD information from perl
module files
[I] virtual/perl-Module-Metadata
Available versions: ~1.0.3 ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1
- Unmasked by --autounmask
Installed versions: 1.0.9-r1(09:37:51 07/02/12)
Description: Virtual for Module-Metadata
perl-Module-Metadata-1.0.9.ebuild
RDEPEND=|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )
It appears yes, --depclean *will* reap perl-core/* in this scenario (
portage 2.2.0_alpha114 )
Just I don't tend to use --depclean an awful lot. Usually, I don't
expect to have to use --depclean to avoid a somewhat broken system.
Doesn't perl-cleaner handle perl upgrades for this? And the tested
ABI_SLOTs should help with that too.
ABI_SLOT may be able to help, but the problem is that installing
perl-core/foo-1.0 on perl-5.10 which ships foo-2.0 , is 100% fine.
It will just shadow the 2.0 version with the 1.0 version, and assume
that is what you want, while the virtual is trying to convey That
is not what we want.
And perl-cleaner doesn't have any code to handle this scenario last I
checked. You can't even work out what is the right installation
scenario without first knowing what do installed packages want. If
installed packages want version foo to be smaller than 2.0 then
perl-core/foo-1.0 being installed on perl-5.10 is Fine . For this,
they would depend on virtual/perl-foo-2 .
In essence, you can't tell if the right perl-core/* is installed
without first looking that what virtual is installed.
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.
Given
C = ^^( a b ) and you had A and C in your world, and you wanted
to install B, portage would tell you that to do that, you would have
to remove either A or C. ( Yay, the communicative property of XOR :D
)
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...
I can't parse this statement. Sorry :/
c) you want portage to unmerge foo because the dep will now be
satisfied by bar. Wait... unmerge perl?
No, perl would never be removed, not unless the ^^( ) was simply
^^( perl foo )
In practice, it would be ^^( =dev-lang/perl-5.16* =foo-5.0 ) which
would mean
a) remove foo
b) downgrade/upgrade dev-lang/perl
of course, I have noticed a fly in my ointment, in that this logic
would mean this blocker could be avoided by down/upgrading foo, which
is precisely what we want to avoid. So its back to the drawing board.
If we were to discard what we currently know about dependencies for a
moment, a dep spec of
perl-Foo-5.0:
if ( =dev-lang/perl-5.10.0 ) {
block versions of perl-core/Foo that are not 5.0
# Because if somebody wants to install perl-core/Foo-5.0 in
perl-5.10 , thats fine, its pointless, but its fine
# because perl-core/Foo-5.0 'provides' Foo-5.0, as does
perl-5.10, so this is satisfactory behaviour
} else {
install perl-core/Foo-5.0 and only perl-core/Foo-5.0
# Because something has stated that it wants Foo-5.0 for some reason,
# So we must deliver it at all costs. If its not shipped in
perl, then we provide it.
}
It would be nice to be able to just say Fine, how about we just
always install from perl-core/.
Which hits the road block as soon as upstream release dev-lang/perl
with Foo-5.01 , and Foo-5.01 is not available on CPAN. ( Sometimes its
a 'dev' release, other times its not ) .
Better approaches welcome.
I have thought of scrapping the virtuals entirely and handling it so
that things depend on perl-core/* instead, and perl-core can just
dynamically decide at install time whether or not it needs to no-op (
and sometimes perl-core/* will need to hard depend on perl and just
install nothing ).
This seems a simpler approach until you consider the problem of How
do we determine dependencies for this ebuild.
Messy. :/
With API_SLOTS I guess we can (maybe) have api-slot conditional
SRC_URI and DEPEND values,
# Not real code, just pesudocode
SRC_URI= ! API-Perl-5.10 ? ( . )
DEPEND= ! API-Perl-5.10 ? ( . )
Or
[gentoo-dev] Package (singular) up for grabs: sys-fs/ext4magic
Don't need or care about this anymore, feel free to pick up if you use it One open bug, http://bugs.gentoo.org/403883
Re: Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
I guess something like this might work in pkg_postinst of the portage ebuild: find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R portage:portage I would only trigger something like this once, when upgrading from a version that doesn't have userpriv enabled by default. If you run ebuild as user (belonging to group portage), that won't help... better add a chmod -R g+w too... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
I guess something like this might work in pkg_postinst of the portage ebuild: find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R portage:portage I would only trigger something like this once, when upgrading from a version that doesn't have userpriv enabled by default. If you run ebuild as user (belonging to group portage), that won't help... better add a chmod -R g+w too... Scratch that. It would not have worked before either, so the user has to do something him/herself either way. I guess we dont have to care for this case. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On Tue, 3 Jul 2012 21:05:46 +1200
Kent Fredric kentfred...@gmail.com wrote:
On 3 July 2012 20:24, Michał Górny mgo...@gentoo.org wrote:
--depclean?
eix Module-Metadata
[I] perl-core/Module-Metadata
Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9---
not unmasked by --autounmask
Installed versions: 1.0.6(15:59:00 06/26/12)
Homepage:http://search.cpan.org/dist/Module-Metadata/
Description: Gather package and POD information from perl
module files
[I] virtual/perl-Module-Metadata
Available versions: ~1.0.3 ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1
- Unmasked by --autounmask
Installed versions: 1.0.9-r1(09:37:51 07/02/12)
Description: Virtual for Module-Metadata
perl-Module-Metadata-1.0.9.ebuild
RDEPEND=|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )
It appears yes, --depclean *will* reap perl-core/* in this scenario (
portage 2.2.0_alpha114 )
Just I don't tend to use --depclean an awful lot. Usually, I don't
expect to have to use --depclean to avoid a somewhat broken system.
Yes. Which simply means that something is broken with dependencies.
And by that I mean that either:
a) || ( a b ) should be || ( b a ), to actually state what perl does,
b) perl should be modified to work like our deps specify.
Doesn't perl-cleaner handle perl upgrades for this? And the tested
ABI_SLOTs should help with that too.
ABI_SLOT may be able to help, but the problem is that installing
perl-core/foo-1.0 on perl-5.10 which ships foo-2.0 , is 100% fine.
It will just shadow the 2.0 version with the 1.0 version, and assume
that is what you want, while the virtual is trying to convey That
is not what we want.
If user intentionally installs an older version, he should be aware
that the result will be having the older version rather than the newer
one. I think we shouldn't prevent that.
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.
Given
C = ^^( a b ) and you had A and C in your world, and you wanted
to install B, portage would tell you that to do that, you would have
to remove either A or C. ( Yay, the communicative property of XOR :D
)
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...
I can't parse this statement. Sorry :/
Nevermind it. It was an assumption that a b could be fine together
later on but I'm not sure if it was really on the topic.
c) you want portage to unmerge foo because the dep will now be
satisfied by bar. Wait... unmerge perl?
No, perl would never be removed, not unless the ^^( ) was simply
^^( perl foo )
In practice, it would be ^^( =dev-lang/perl-5.16* =foo-5.0 ) which
would mean
a) remove foo
b) downgrade/upgrade dev-lang/perl
of course, I have noticed a fly in my ointment, in that this logic
would mean this blocker could be avoided by down/upgrading foo, which
is precisely what we want to avoid. So its back to the drawing board.
I don't really think we allow blockers to enforce upgrades/downgrades.
I have thought of scrapping the virtuals entirely and handling it so
that things depend on perl-core/* instead, and perl-core can just
dynamically decide at install time whether or not it needs to no-op (
and sometimes perl-core/* will need to hard depend on perl and just
install nothing ).
This seems a simpler approach until you consider the problem of How
do we determine dependencies for this ebuild.
Do you actually need to do that? All those ebuilds will depend on perl
with minimal version number necessary for the package to build.
If perl is older, the package will be built normally. If perl is newer,
the package will install a no-op. It's fine unless you consider
downgrading perl. But thinking about it... any upgrade or downgrade of
perl breaks all the modules anyway.
About other package dependencies, they're probably fine in both cases.
If a newer perl provides the particular module, all its dependencies
have to be satisfied in perl anyway. So it will just pull more
'virtuals'.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] grub:2 keywords
On Mon, 2 Jul 2012 15:02:28 -0400 Mike Gilbert flop...@gentoo.org wrote: That is exactly what Doug (cardoe) proposed, and he is working on the docs for that. Ah yes, it's been a long-winded thread. :) jer
Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/07/12 05:05 AM, Kent Fredric wrote:
On 3 July 2012 20:24, Michał Górny mgo...@gentoo.org wrote:
--depclean?
eix Module-Metadata [I] perl-core/Module-Metadata Available
versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9--- not unmasked
by --autounmask Installed versions: 1.0.6(15:59:00 06/26/12)
Homepage:http://search.cpan.org/dist/Module-Metadata/
Description: Gather package and POD information from perl
module files
[I] virtual/perl-Module-Metadata Available versions: ~1.0.3
~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1 - Unmasked by --autounmask
Installed versions: 1.0.9-r1(09:37:51 07/02/12) Description:
Virtual for Module-Metadata
perl-Module-Metadata-1.0.9.ebuild
RDEPEND=|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )
It appears yes, --depclean *will* reap perl-core/* in this scenario
( portage 2.2.0_alpha114 )
Just I don't tend to use --depclean an awful lot. Usually, I don't
expect to have to use --depclean to avoid a somewhat broken
system.
Doesn't perl-cleaner handle perl upgrades for this? And the
tested ABI_SLOTs should help with that too.
Just to add a note in here, since the perl stuff is one of the first
things I converted to 4-slot-abi, unfortunately, no it doesn't seem
that ABI slots are going to help with this. Sub-slots will trigger
rebuilds of anything built against an older perl when it's upgraded,
but it seems to have no effect on any of the virtual/perl-* stuff.
The only effect it may have is giving the ability to specify perl
versions via slots instead of wildcard-versions (ie:
=dev-lang/perl-5.16* would become dev-lang/perl:0/5.16 )
Some of these perl virtuals have rather convoluted perl versions
(like, all 5.16, all 5.14, only 2 versions of 5.12, and a particular
version of 5.10), and so I don't think sub-slot deps will help the
situation here as i don't think we could align the sub-slot bumps by
feature set, at least not right now..
One thing that sub-slots ARE doing, though, is they are (as far as I
can tell) not triggering rebuilds for any installed packages that are
superseded (and therefore their virtual is now satisfied) by the newer
perl. I realize this didn't occur before either, but I don't know if
perl-cleaner handled their removal or not (or if perl-cleaner actually
rebuilt them)?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAk/zClIACgkQ2ugaI38ACPDIPwEAkd6hlmoMQ4SRhvkttoyP11ih
EKoR+tUNaMEqeb87T34A/irG+h8tPolXKsJQtEoRKr5xIGvWDYT83LlmV4fbOwui
=Vf92
-END PGP SIGNATURE-
Re: [gentoo-dev] Package (singular) up for grabs: sys-fs/ext4magic
On Tue, Jul 03, 2012 at 03:05:46PM +0300, Samuli Suominen wrote: Don't need or care about this anymore, feel free to pick up if you use it One open bug, http://bugs.gentoo.org/403883 Is this bug still valid if there's 0.3.0 in portage and 0.2.4 is gone? Piotr Szymaniak. -- W celi byla prycza przytwierdzona do sciany i metalowy pojemnik bez sedesu. Mogles spedzac czas na trzy sposoby: siedzac, srajac lub spiac. Niezly wybor. -- Stephen King, Rita Hayworth and Shawshank Redemption signature.asc Description: Digital signature
[gentoo-dev] Lastrite app-laptop/lenovo-sl-laptop
# Ben de Groot yng...@gentoo.org (3 Jul 2012) # Dead upstream. Doesn't compile with current kernels. # Removal in 30 days. app-laptop/lenovo-sl-laptop -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On 4 July 2012 02:16, Michał Górny mgo...@gentoo.org wrote: I have thought of scrapping the virtuals entirely and handling it so that things depend on perl-core/* instead, and perl-core can just dynamically decide at install time whether or not it needs to no-op ( and sometimes perl-core/* will need to hard depend on perl and just install nothing ). This seems a simpler approach until you consider the problem of How do we determine dependencies for this ebuild. Do you actually need to do that? All those ebuilds will depend on perl with minimal version number necessary for the package to build. If perl is older, the package will be built normally. If perl is newer, the package will install a no-op. It's fine unless you consider downgrading perl. But thinking about it... any upgrade or downgrade of perl breaks all the modules anyway. The problem occurs in a few edge cases, which, fortunately don't happen often. Usually its when packages appear as new additions to dev-lang/perl. ie: When AAA is added to perl, on perls older than 5.something have to install all of AA's deps . ( Which are ussually provided by perl anyway, so its not a problem ). But if *2* things are added between perl releases and one depends on the other, ie: AAA and BBB are added to perl 20, installing them on perl 15 will require you to install BBB before installing AAA. Granted I can't think of any modules that do exactly this off the top of my head, but its something to think about. ( Perhaps some things like CPANPLUS and other things that are miles ahead of the perl verision and have external deps ), but fair to say, I think a module that can a) sometimes install code from CPAN but b) has no DEPENDS on other perl modules ( because you want to have no depends if it is going to just no-op ) Is a recipe for disaster. And the more I think about doing it with USE_EXPAND/USE flags with 1-flag-perl-perl-version[1] the more It feels like it would be a bigger nightmare than what we're currently doing. What we're doing works atm, just it has the annoying quirks that come up from time to time, notably more around perl releases, and these quirks slowdown stabilizations. *1 : ( though they've tended away from changing versions of bundled libs with maintenance releases these days so its not so much a visible problem if we stick to the Majors, it can still happen that the version of a module can change between releases, and somebody could plausibly depend on the more recent of the 2 versions ) If a newer perl provides the particular module, all its dependencies have to be satisfied in perl anyway. So it will just pull more 'virtuals'. -- Best regards, Michał Górny -- 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
Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND
On Tue, 3 Jul 2012 20:24:43 +1200 Kent Fredric kentfred...@gmail.com wrote: On 3 July 2012 19:08, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 3 Jul 2012 15:44:04 +1200 Kent Fredric kentfred...@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 signature.asc Description: PGP signature
Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On 4 July 2012 02:16, Michał Górny mgo...@gentoo.org wrote: a) || ( a b ) should be || ( b a ), to actually state what perl does, I don't really see how that would help much, if anything, I get the impression that would 1) needlessly install b even when it could be satisfied by a instead ( ie: before both a b are installed ) 2) be more inclined to keep a than it currently does 3) Probably not help in the situation I had above with =perl-core/Module-Metadata-1.0.6 ( stable , 1.0.9 is masked by ~ still ) =virtual/perl-Module-Metadata-1.0.9( --autounmasked from ~ ) =dev-lang/perl-5.16.0 ( --autounmasked from ~ ) As after installing perl-5.16.0, the || ( ) is again satisfied, rending the system somewhat broken, but having to wait for --depclean before it comes right. But I'm possibly wrong somewhere, I may have fundamentally misunderstood how || ( ) works. On 4 July 2012 02:16, Michał Górny mgo...@gentoo.org wrote: b) perl should be modified to work like our deps specify. That's probably the most difficult task of all, I think you'd have to shred modules out of perl and hand package them into perl-core/ packages for that, and then never install them as part of perl, despite the fact some of perl won't even build without some of those modules in its tree ( so you have to remove them during install ), and thats the start of all sorts of fun bootstrapping things I wont touch dipped head-to-toe in antiseptic. -- 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
Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND
On 4 July 2012 05:56, Ciaran McCreesh ciaran.mccre...@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
Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On Wed, 4 Jul 2012 05:49:08 +1200 Kent Fredric kentfred...@gmail.com wrote: On 4 July 2012 02:16, Michał Górny mgo...@gentoo.org wrote: I have thought of scrapping the virtuals entirely and handling it so that things depend on perl-core/* instead, and perl-core can just dynamically decide at install time whether or not it needs to no-op ( and sometimes perl-core/* will need to hard depend on perl and just install nothing ). This seems a simpler approach until you consider the problem of How do we determine dependencies for this ebuild. Do you actually need to do that? All those ebuilds will depend on perl with minimal version number necessary for the package to build. If perl is older, the package will be built normally. If perl is newer, the package will install a no-op. It's fine unless you consider downgrading perl. But thinking about it... any upgrade or downgrade of perl breaks all the modules anyway. The problem occurs in a few edge cases, which, fortunately don't happen often. Usually its when packages appear as new additions to dev-lang/perl. ie: When AAA is added to perl, on perls older than 5.something have to install all of AA's deps . ( Which are ussually provided by perl anyway, so its not a problem ). But if *2* things are added between perl releases and one depends on the other, ie: AAA and BBB are added to perl 20, installing them on perl 15 will require you to install BBB before installing AAA. Granted I can't think of any modules that do exactly this off the top of my head, but its something to think about. ( Perhaps some things like CPANPLUS and other things that are miles ahead of the perl verision and have external deps ), but fair to say, I think a module that can a) sometimes install code from CPAN but b) has no DEPENDS on other perl modules ( because you want to have no depends if it is going to just no-op ) Is a recipe for disaster. I was saying the other way -- always specify the complete deps. If you install it on older perl, it will work. If you install it on newer perl, it shouldn't involve installing anything which is not necessary (or already integrated into perl) anyway. And the more I think about doing it with USE_EXPAND/USE flags with 1-flag-perl-perl-version[1] the more It feels like it would be a bigger nightmare than what we're currently doing. What we're doing works atm, just it has the annoying quirks that come up from time to time, notably more around perl releases, and these quirks slowdown stabilizations. *1 : ( though they've tended away from changing versions of bundled libs with maintenance releases these days so its not so much a visible problem if we stick to the Majors, it can still happen that the version of a module can change between releases, and somebody could plausibly depend on the more recent of the 2 versions ) If a newer perl provides the particular module, all its dependencies have to be satisfied in perl anyway. So it will just pull more 'virtuals'. -- Best regards, Michał Górny -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] freebsd.eclass change
On Mon, 02 Jul 2012 14:09:26 -0400
Richard Yao r...@gentoo.org wrote:
On 07/02/2012 02:02 PM, Mike Frysinger wrote:
On Monday 02 July 2012 13:37:53 Richard Yao wrote:
On 07/02/2012 10:54 AM, Alexis Ballier wrote:
hu? yes, as already pointed out, uname is not reliable when
cross-compiling. You should use CHOST, and then you get
tc-arch-kernel. See freebsd-lib ebuild for how it is handled.
In that case, it should be 'local arch=$(tc-arch-kernel)'. Using
tc-arch-kernel by itself causes problems when building on Linux,
because x86 can be passed, which FreeBSD's build system does not
understand.
the function specifically handles freebsd in this case. why isn't
that code sufficient ?
Also, this function is not meant for cross compilation.
then it doesn't really belong in the tree. native builds are just
a special case of cross-compiling.
-mike
The idea is to use this to assist in building parts of FreeBSD on
Linux for Linux (or on Prefix for whatever platform it runs). Anyway,
I will keep this in ebuilds until it has several ebuilds using it.
Then we can revisit it.
you probably want something like:
tc-arch-kernel ${CHOST%%-*}-gentoo-freebsd9.0
then
we do not really care about the version suffix in tc-arch functions, so
you can also omit it.
A.
[gentoo-portage-dev] Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On 3 July 2012 20:24, Michał Górny mgo...@gentoo.org wrote:
--depclean?
eix Module-Metadata
[I] perl-core/Module-Metadata
Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9---
not unmasked by --autounmask
Installed versions: 1.0.6(15:59:00 06/26/12)
Homepage:http://search.cpan.org/dist/Module-Metadata/
Description: Gather package and POD information from perl
module files
[I] virtual/perl-Module-Metadata
Available versions: ~1.0.3 ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1
- Unmasked by --autounmask
Installed versions: 1.0.9-r1(09:37:51 07/02/12)
Description: Virtual for Module-Metadata
perl-Module-Metadata-1.0.9.ebuild
RDEPEND=|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )
It appears yes, --depclean *will* reap perl-core/* in this scenario (
portage 2.2.0_alpha114 )
Just I don't tend to use --depclean an awful lot. Usually, I don't
expect to have to use --depclean to avoid a somewhat broken system.
Doesn't perl-cleaner handle perl upgrades for this? And the tested
ABI_SLOTs should help with that too.
ABI_SLOT may be able to help, but the problem is that installing
perl-core/foo-1.0 on perl-5.10 which ships foo-2.0 , is 100% fine.
It will just shadow the 2.0 version with the 1.0 version, and assume
that is what you want, while the virtual is trying to convey That
is not what we want.
And perl-cleaner doesn't have any code to handle this scenario last I
checked. You can't even work out what is the right installation
scenario without first knowing what do installed packages want. If
installed packages want version foo to be smaller than 2.0 then
perl-core/foo-1.0 being installed on perl-5.10 is Fine . For this,
they would depend on virtual/perl-foo-2 .
In essence, you can't tell if the right perl-core/* is installed
without first looking that what virtual is installed.
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.
Given
C = ^^( a b ) and you had A and C in your world, and you wanted
to install B, portage would tell you that to do that, you would have
to remove either A or C. ( Yay, the communicative property of XOR :D
)
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...
I can't parse this statement. Sorry :/
c) you want portage to unmerge foo because the dep will now be
satisfied by bar. Wait... unmerge perl?
No, perl would never be removed, not unless the ^^( ) was simply
^^( perl foo )
In practice, it would be ^^( =dev-lang/perl-5.16* =foo-5.0 ) which
would mean
a) remove foo
b) downgrade/upgrade dev-lang/perl
of course, I have noticed a fly in my ointment, in that this logic
would mean this blocker could be avoided by down/upgrading foo, which
is precisely what we want to avoid. So its back to the drawing board.
If we were to discard what we currently know about dependencies for a
moment, a dep spec of
perl-Foo-5.0:
if ( =dev-lang/perl-5.10.0 ) {
block versions of perl-core/Foo that are not 5.0
# Because if somebody wants to install perl-core/Foo-5.0 in
perl-5.10 , thats fine, its pointless, but its fine
# because perl-core/Foo-5.0 'provides' Foo-5.0, as does
perl-5.10, so this is satisfactory behaviour
} else {
install perl-core/Foo-5.0 and only perl-core/Foo-5.0
# Because something has stated that it wants Foo-5.0 for some reason,
# So we must deliver it at all costs. If its not shipped in
perl, then we provide it.
}
It would be nice to be able to just say Fine, how about we just
always install from perl-core/.
Which hits the road block as soon as upstream release dev-lang/perl
with Foo-5.01 , and Foo-5.01 is not available on CPAN. ( Sometimes its
a 'dev' release, other times its not ) .
Better approaches welcome.
I have thought of scrapping the virtuals entirely and handling it so
that things depend on perl-core/* instead, and perl-core can just
dynamically decide at install time whether or not it needs to no-op (
and sometimes perl-core/* will need to hard depend on perl and just
install nothing ).
This seems a simpler approach until you consider the problem of How
do we determine dependencies for this ebuild.
Messy. :/
With API_SLOTS I guess we can (maybe) have api-slot conditional
SRC_URI and DEPEND values,
# Not real code, just pesudocode
SRC_URI= ! API-Perl-5.10 ? ( . )
DEPEND= ! API-Perl-5.10 ? ( . )
Or
[gentoo-portage-dev] Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On 4 July 2012 02:16, Michał Górny mgo...@gentoo.org wrote: I have thought of scrapping the virtuals entirely and handling it so that things depend on perl-core/* instead, and perl-core can just dynamically decide at install time whether or not it needs to no-op ( and sometimes perl-core/* will need to hard depend on perl and just install nothing ). This seems a simpler approach until you consider the problem of How do we determine dependencies for this ebuild. Do you actually need to do that? All those ebuilds will depend on perl with minimal version number necessary for the package to build. If perl is older, the package will be built normally. If perl is newer, the package will install a no-op. It's fine unless you consider downgrading perl. But thinking about it... any upgrade or downgrade of perl breaks all the modules anyway. The problem occurs in a few edge cases, which, fortunately don't happen often. Usually its when packages appear as new additions to dev-lang/perl. ie: When AAA is added to perl, on perls older than 5.something have to install all of AA's deps . ( Which are ussually provided by perl anyway, so its not a problem ). But if *2* things are added between perl releases and one depends on the other, ie: AAA and BBB are added to perl 20, installing them on perl 15 will require you to install BBB before installing AAA. Granted I can't think of any modules that do exactly this off the top of my head, but its something to think about. ( Perhaps some things like CPANPLUS and other things that are miles ahead of the perl verision and have external deps ), but fair to say, I think a module that can a) sometimes install code from CPAN but b) has no DEPENDS on other perl modules ( because you want to have no depends if it is going to just no-op ) Is a recipe for disaster. And the more I think about doing it with USE_EXPAND/USE flags with 1-flag-perl-perl-version[1] the more It feels like it would be a bigger nightmare than what we're currently doing. What we're doing works atm, just it has the annoying quirks that come up from time to time, notably more around perl releases, and these quirks slowdown stabilizations. *1 : ( though they've tended away from changing versions of bundled libs with maintenance releases these days so its not so much a visible problem if we stick to the Majors, it can still happen that the version of a module can change between releases, and somebody could plausibly depend on the more recent of the 2 versions ) If a newer perl provides the particular module, all its dependencies have to be satisfied in perl anyway. So it will just pull more 'virtuals'. -- Best regards, Michał Górny -- 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
[gentoo-portage-dev] Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )
On 4 July 2012 02:16, Michał Górny mgo...@gentoo.org wrote: a) || ( a b ) should be || ( b a ), to actually state what perl does, I don't really see how that would help much, if anything, I get the impression that would 1) needlessly install b even when it could be satisfied by a instead ( ie: before both a b are installed ) 2) be more inclined to keep a than it currently does 3) Probably not help in the situation I had above with =perl-core/Module-Metadata-1.0.6 ( stable , 1.0.9 is masked by ~ still ) =virtual/perl-Module-Metadata-1.0.9( --autounmasked from ~ ) =dev-lang/perl-5.16.0 ( --autounmasked from ~ ) As after installing perl-5.16.0, the || ( ) is again satisfied, rending the system somewhat broken, but having to wait for --depclean before it comes right. But I'm possibly wrong somewhere, I may have fundamentally misunderstood how || ( ) works. On 4 July 2012 02:16, Michał Górny mgo...@gentoo.org wrote: b) perl should be modified to work like our deps specify. That's probably the most difficult task of all, I think you'd have to shred modules out of perl and hand package them into perl-core/ packages for that, and then never install them as part of perl, despite the fact some of perl won't even build without some of those modules in its tree ( so you have to remove them during install ), and thats the start of all sorts of fun bootstrapping things I wont touch dipped head-to-toe in antiseptic. -- 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
