Re: [gentoo-dev] Extending EAPI=4
2010-11-19 16:51:03 Zac Medico napisał(a):
On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
use.unsatisfiable and package.use.unsatisfiable files would cause that
`repoman` would treat
given USE flags in the same way as masked USE flags. These files wouldn't
affect behavior of
`emerge`:
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag are already
installed or satisfiable,
then `emerge` will allow to install given package.
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag cannot be
satisfied (with current
settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then
`emerge` will print
informative error message telling e.g. about a dependency masked by
~${ARCH} keyword.
Can't we print a masked by ~${ARCH} keyword message as you suggest,
even without the use.unsatisfiable data? If so, then isn't
use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
use.mask, so I don't see any value added.
repoman sometimes needs to allow stable packages to have optional dependencies
on unstable
packages (usually until these packages are stabilized). My patch implements
this functionality
for repoman.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
On 11/28/2010 10:15 AM, Arfrever Frehtes Taifersar Arahesis wrote:
2010-11-19 16:51:03 Zac Medico napisał(a):
On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
use.unsatisfiable and package.use.unsatisfiable files would cause that
`repoman` would treat
given USE flags in the same way as masked USE flags. These files wouldn't
affect behavior of
`emerge`:
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag are already
installed or satisfiable,
then `emerge` will allow to install given package.
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag cannot be
satisfied (with current
settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then
`emerge` will print
informative error message telling e.g. about a dependency masked by
~${ARCH} keyword.
Can't we print a masked by ~${ARCH} keyword message as you suggest,
even without the use.unsatisfiable data? If so, then isn't
use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
use.mask, so I don't see any value added.
repoman sometimes needs to allow stable packages to have optional
dependencies on unstable
packages (usually until these packages are stabilized). My patch implements
this functionality
for repoman.
It seems like you're trying to bypass an important function of repoman
though. The idea is that repoman is supposed to protect users from
experiencing unsatisfiable dependencies of this sort, and use.mask
accomplishes that. With your use.unsatisfiable patch, it makes repoman
quiet, while leaving users unprotected from unsatisfied dependencies.
--
Thanks,
Zac
Re: [gentoo-dev] Extending EAPI=4
2010-11-28 20:59:05 Zac Medico napisał(a):
On 11/28/2010 10:15 AM, Arfrever Frehtes Taifersar Arahesis wrote:
2010-11-19 16:51:03 Zac Medico napisał(a):
On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
use.unsatisfiable and package.use.unsatisfiable files would cause that
`repoman` would treat
given USE flags in the same way as masked USE flags. These files wouldn't
affect behavior of
`emerge`:
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag are already
installed or satisfiable,
then `emerge` will allow to install given package.
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag cannot be
satisfied (with current
settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then
`emerge` will print
informative error message telling e.g. about a dependency masked by
~${ARCH} keyword.
Can't we print a masked by ~${ARCH} keyword message as you suggest,
even without the use.unsatisfiable data? If so, then isn't
use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
use.mask, so I don't see any value added.
repoman sometimes needs to allow stable packages to have optional
dependencies on unstable
packages (usually until these packages are stabilized). My patch implements
this functionality
for repoman.
It seems like you're trying to bypass an important function of repoman
though. The idea is that repoman is supposed to protect users from
experiencing unsatisfiable dependencies of this sort, and use.mask
accomplishes that.
If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are
masked using use.mask
on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these
architectures, then
majority of reverse dependencies of Python wouldn't be tested with new versions
of Python.
Example {,R}DEPEND:
python_abis_2.4? ( dev-lang/python:2.4 )
python_abis_2.5? ( dev-lang/python:2.5 )
python_abis_2.6? ( dev-lang/python:2.6 )
python_abis_2.7? ( dev-lang/python:2.7 )
python_abis_3.0? ( dev-lang/python:3.0 )
python_abis_3.1? ( dev-lang/python:3.1 )
python_abis_3.2? ( dev-lang/python:3.2 )
python_abis_2.5-jython? ( dev-java/jython:2.5 )
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
On 11/28/2010 12:07 PM, Arfrever Frehtes Taifersar Arahesis wrote:
2010-11-28 20:59:05 Zac Medico napisał(a):
It seems like you're trying to bypass an important function of repoman
though. The idea is that repoman is supposed to protect users from
experiencing unsatisfiable dependencies of this sort, and use.mask
accomplishes that.
If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are
masked using use.mask
on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these
architectures, then
majority of reverse dependencies of Python wouldn't be tested with new
versions of Python.
Example {,R}DEPEND:
python_abis_2.4? ( dev-lang/python:2.4 )
python_abis_2.5? ( dev-lang/python:2.5 )
python_abis_2.6? ( dev-lang/python:2.6 )
python_abis_2.7? ( dev-lang/python:2.7 )
python_abis_3.0? ( dev-lang/python:3.0 )
python_abis_3.1? ( dev-lang/python:3.1 )
python_abis_3.2? ( dev-lang/python:3.2 )
python_abis_2.5-jython? ( dev-java/jython:2.5 )
It seems like the problem here is that we don't have separate profiles
for stable and unstable keywords. The obvious solution would be to have
separate profiles, mask the flags in the stable profiles, and unmask the
flags in the unstable profiles. That way, repoman would continue to
protect stable profile users from unsatisfiable dependencies, without
unnecessarily masking those choices from unstable profile users.
--
Thanks,
Zac
Re: [gentoo-dev] Extending EAPI=4
2010-11-28 21:30:47 Zac Medico napisał(a):
On 11/28/2010 12:07 PM, Arfrever Frehtes Taifersar Arahesis wrote:
2010-11-28 20:59:05 Zac Medico napisał(a):
It seems like you're trying to bypass an important function of repoman
though. The idea is that repoman is supposed to protect users from
experiencing unsatisfiable dependencies of this sort, and use.mask
accomplishes that.
If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are
masked using use.mask
on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on
these architectures, then
majority of reverse dependencies of Python wouldn't be tested with new
versions of Python.
Example {,R}DEPEND:
python_abis_2.4? ( dev-lang/python:2.4 )
python_abis_2.5? ( dev-lang/python:2.5 )
python_abis_2.6? ( dev-lang/python:2.6 )
python_abis_2.7? ( dev-lang/python:2.7 )
python_abis_3.0? ( dev-lang/python:3.0 )
python_abis_3.1? ( dev-lang/python:3.1 )
python_abis_3.2? ( dev-lang/python:3.2 )
python_abis_2.5-jython? ( dev-java/jython:2.5 )
It seems like the problem here is that we don't have separate profiles
for stable and unstable keywords. The obvious solution would be to have
separate profiles, mask the flags in the stable profiles, and unmask the
flags in the unstable profiles. That way, repoman would continue to
protect stable profile users from unsatisfiable dependencies, without
unnecessarily masking those choices from unstable profile users.
I would prefer small number of additional files instead of huge proliferation
of profiles.
You also suggested using EAPI=4-specific profiles instead of EAPI-versioned
files, so eventually
we might have about 4 times more profiles :) .
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
On 11/28/2010 11:56 PM, Arfrever Frehtes Taifersar Arahesis wrote: It seems like the problem here is that we don't have separate profiles for stable and unstable keywords. The obvious solution would be to have separate profiles, mask the flags in the stable profiles, and unmask the flags in the unstable profiles. That way, repoman would continue to protect stable profile users from unsatisfiable dependencies, without unnecessarily masking those choices from unstable profile users. I would prefer small number of additional files instead of huge proliferation of profiles. You also suggested using EAPI=4-specific profiles instead of EAPI-versioned files, so eventually we might have about 4 times more profiles :) . There's no requirement to keep old profiles around indefinitely. Old profiles will eventually go away once the new ones are the recommended option. As for this particular case I haven't really taken a close enough opinion to say if new profiles make the best sense or not. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Extending EAPI=4
On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
use.unsatisfiable and package.use.unsatisfiable files would cause that
`repoman` would treat
given USE flags in the same way as masked USE flags. These files wouldn't
affect behavior of
`emerge`:
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag are already
installed or satisfiable,
then `emerge` will allow to install given package.
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag cannot be
satisfied (with current
settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then
`emerge` will print
informative error message telling e.g. about a dependency masked by
~${ARCH} keyword.
Can't we print a masked by ~${ARCH} keyword message as you suggest,
even without the use.unsatisfiable data? If so, then isn't
use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
use.mask, so I don't see any value added.
As an alternative, I'd suggest an atom syntax extension to indicate that
a given atom is optional. For example, we could borrow the '?' character
from regular expression syntax, and append '?' to the right side of an
atom in order to indicate that it is an optional atom.
[1]
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=93ee6a847be949e7752c3c052d3eb0619e408b43
--
Thanks,
Zac
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 16:03:01 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:56:18 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-10-25 15:42:00 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? There won't be any such USE flags for EAPI 4. Ok, that answers that objection. In that case I'd not be opposed to . being allowed *provided*: - Portage explicitly enforces it not being allowed anywhere else, including in profiles that aren't marked as eapi 4 I have implemented validation of syntax of USE flags in files in profiles: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=9e9c822aae0c3daab208175025b161d6d34877fe -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Extending EAPI=4
I would like to request that 2 additional features are added to EAPI=4.
These features will be needed for further development of python.eclass.
1. Support for . characters in names of USE flags
2. Support for use.unsatisfiable and package.use.unsatisfiable files in profiles
These files would have the same syntax as use.mask and package.use.mask,
respectively.
These files would indicate that it's allowed for dependencies conditional on
USE flags specified
in these files to be unsatisfiable. It would allow for stable packages to have
optional
dependencies on packages, which cannot be stabilized yet. This feature would be
a better
replacement for possibility of masking of USE flags only on stable systems,
which was considered
in the past.
Example dependencies:
DEPEND=python_abis_2.4? ( dev-lang/python:2.4 )
python_abis_2.5? ( dev-lang/python:2.5 )
python_abis_2.6? ( dev-lang/python:2.6 )
python_abis_2.7? ( dev-lang/python:2.7 )
python_abis_3.1? ( dev-lang/python:3.1 )
python_abis_3.2? ( dev-lang/python:3.2 )
RDEPEND=${DEPEND}
python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags would be
specified in use.unsatisfiable
file until relevant versions of Python are stabilized on all architectures.
Without this feature,
some USE flags would have to be masked, so unstable users couldn't easily test
many packages with
new versions of Python.
Another example: dev-vcs/subversion[kde] depends on =kde-base/kdelibs-4.
dev-vcs/subversion is
stable on arm and ppc64, but kde-base/kdelibs is unstable on these
architectures, which causes
that currently kde USE flag of dev-vcs/subversion is masked in arm and ppc64
profiles, which
causes that users of ~arm or ~ppc64 would have to manually unmask this USE flag
in
/etc/portage/profile/package.use.mask to be able to install dev-vcs/subversion
with kde USE flag
enabled. With this feature, users wouldn't need to edit
/etc/portage/profile/package.use.mask.
use.unsatisfiable and package.use.unsatisfiable files would cause that
`repoman` would treat
given USE flags in the same way as masked USE flags. These files wouldn't
affect behavior of
`emerge`:
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag are already
installed or satisfiable,
then `emerge` will allow to install given package.
- If user has enabled given USE flag specified in use.unsatisfiable or
package.use.unsatisfiable
and if optional dependencies controlled by this USE flag cannot be satisfied
(with current
settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then
`emerge` will print
informative error message telling e.g. about a dependency masked by ~${ARCH}
keyword.
I have a patch, which adds support for these features in Portage, so inclusion
of these features
in EAPI=4 wouldn't delay EAPI=4.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? And won't developers have a hard time getting [use] deps right for them? 2. Support for use.unsatisfiable and package.use.unsatisfiable files in profiles As far as I can see, this one's a repoman thing, and has little to no impact on PMS since it doesn't require behaviour changes from the package mangler itself. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 15:42:00 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? There won't be any such USE flags for EAPI 4. I'm planning to use e.g. REQUIRED_USE, which isn't available in EAPI 4. And won't developers have a hard time getting [use] deps right for them? Appropriate dependencies will be automatically generated by python.eclass. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 15:56:50 Ulrich Mueller napisał(a): On Mon, 25 Oct 2010, Arfrever Frehtes Taifersar Arahesis wrote: 1. Support for . characters in names of USE flags Are you aware that this would break existing programs that do regexp matching on USE flags? I suggest this feature in a new EAPI to avoid this problem. (No program should parse anything from future EAPIs.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
On Mon, 25 Oct 2010 15:56:50 +0200 Ulrich Mueller u...@gentoo.org wrote: On Mon, 25 Oct 2010, Arfrever Frehtes Taifersar Arahesis wrote: 1. Support for . characters in names of USE flags Are you aware that this would break existing programs that do regexp matching on USE flags? The current implementation of the useq() function in portage is probably the most prominent example. That's already a can of worms, since @ is allowed in use flag names. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Extending EAPI=4
Implementing a feature to just satisfy your tiny, corner-case (how many people would take benefit out of it?) use case is just against any software engineering best practice, and it's a good path towards bloat and complexity. I think people can understand python_abis_2_5 well enough, besides being happy that their app will KEEP working. -- Fabio Erculiani
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 16:43:43 Fabio Erculiani napisał(a): Implementing a feature to just satisfy your tiny, corner-case (how many people would take benefit out of it?) use case is just against any software engineering best practice, and it's a good path towards bloat and complexity. I think people can understand python_abis_2_5 well enough, besides being happy that their app will KEEP working. 2_5 is very ugly and unacceptable. python.eclass already uses 2.5 (e.g. in RESTRICT_PYTHON_ABIS). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
2010-10-25 16:03:01 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:56:18 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2010-10-25 15:42:00 Ciaran McCreesh napisał(a): On Mon, 25 Oct 2010 15:24:23 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 1. Support for . characters in names of USE flags If you do this, you'll have to either convert everything using Python ABIs to EAPI 4 immediately, or have two sets of flag names. Won't users get confused if they have to set both python_abis_3_2 (for EAPI 4 packages) and python_abis_3.2 (for EAPI 4 packages)? There won't be any such USE flags for EAPI 4. Ok, that answers that objection. In that case I'd not be opposed to . being allowed *provided*: - Portage explicitly enforces it not being allowed anywhere else, including in profiles that aren't marked as eapi 4 Portage already allows some characters in some places in EAPI=0 regardless of PMS :) . Anyway I don't care. - The . isn't legal as the first character in a flag name. (Paludis has been using [.foo=bar] and the like in user eapi contexts to allow fancy queries on metadata. It would be a shame to have to change that syntax just for some hypothetical possible use of . in use flag names that looks really really weird anyway.) No objection. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Extending EAPI=4
Am 25.10.2010 16:43, schrieb Fabio Erculiani: Implementing a feature to just satisfy your tiny, corner-case (how many people would take benefit out of it?) use case is just against any software engineering best practice, and it's a good path towards bloat and complexity. I think people can understand python_abis_2_5 well enough, besides being happy that their app will KEEP working. You are wrong at this part. Supporting dots in USE flags is not just a corner case for python packages. I planned to suggest the same for a future EAPI, when i got my planned features for multilib-portage done (which will then natively support the installation of packages for multiple versions of those different lang packages (like python, ruby, php...). While it might be possible to read and understand, that 2_5 is intended to be 2.5, it is much easier to understand and read, if you just write 2.5. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Extending EAPI=4
On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote: I would like to request that 2 additional features are added to EAPI=4. These features will be needed for further development of python.eclass. 1. Support for . characters in names of USE flags Ideally we should have consistency across languages so if we go down this road then for example ruby should eventually support it too. Ruby people: can you provide your input. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Extending EAPI=4
Il giorno lun, 25/10/2010 alle 19.23 +0300, Petteri Räty ha scritto: Ideally we should have consistency across languages so if we go down this road then for example ruby should eventually support it too. Ruby people: can you provide your input. We don't really care since we use the Ruby basename, which is dot-free, whatever the reason for that, may even be historical. I don't think our users mind if it's ruby18 or ruby1.8… beside maybe the Funtoo guys since Daniel decided to go with ruby1.9 breaking the previous series of ruby16, ruby18 and ruby19. But especially since _our_ system of dependencies is already in place, we most certainly have no intention on going on to change it on all the packages, so the '.' is totally useless for our scope. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] Extending EAPI=4
On 10/25/2010 06:23 PM, Petteri Räty wrote: On 10/25/2010 04:24 PM, Arfrever Frehtes Taifersar Arahesis wrote: I would like to request that 2 additional features are added to EAPI=4. These features will be needed for further development of python.eclass. 1. Support for . characters in names of USE flags Ideally we should have consistency across languages so if we go down this road then for example ruby should eventually support it too. Ruby people: can you provide your input. PHP could potentially benefit from this, we currently (see php-ext-source-r2.eclass) have to use - instead of the dot. But to my eyes the ugliness is acceptable. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Extending EAPI=4
I would like to suggest that EAPI=4 be reopened for ability of using dots in USE flag names, which was suggested in bug #311795. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
