Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sat, Sep 17, 2011 at 10:26:57PM -0700, Zac Medico wrote: On 09/17/2011 08:47 PM, Donnie Berkholz wrote: On 14:06 Fri 16 Sep , Zac Medico wrote: Bumping the EAPI of the root profiles/eapi file would be a different matter, since it applies to the whole repository. If you want to version bump that repository-level EAPI, then you need to wait until at least 6 months after supporting package managers have been available in stable. So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 now? Yes, it's feasible. As a consequence, we may get some complaints from users who haven't upgraded during the last six months. Bit more than complaints; any system running a PM older than 6 months or so (regardless of paludis/portage/pkgcore) will have to roll their own profile to merge *anything*. Period. A pkg going to an unsupported eapi precludes the package from being used; bumping the root profile node to 4 (or any node in the users chain) means they /cannot use that profile/. If people are seriously going to pull something this level of heinous, at the very least plan it- it's a sizable enough breakage other things could/should be shoved in (including giving people significant warning). To be absolutely clear, You bump the base to EAPI4, you're actively making every system w/ a 6 month lag basically invalidated. For reference of the actual eapi usage in the tree (pinspect eapi_usage), is the following: eapi: '0' 10629 pkgs found, 36.73% of the repository eapi: '2' 7254 pkgs found, 25.07% of the repository eapi: '3' 5315 pkgs found, 18.37% of the repository eapi: '4' 5013 pkgs found, 17.32% of the repository eapi: '1' 728 pkgs found, 2.52% of the repository For users like these, we could take a snapshot of the tree before the EAPI is bumped, and archive it so they can use it to update their package manager to a version that supports the new EAPI. Target the profiles; no need to snapshot the whole tree unless the plan is to bump 83% of the tree forward to EAPI4 shortly there after (which is mildly rediculous in it's own anyways)... ~harring
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sat, 17 Sep 2011, Zac Medico wrote: So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 now? Yes, it's feasible. As a consequence, we may get some complaints from users who haven't upgraded during the last six months. http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt # Vote (unanimous): The ebuild tree must provide an upgrade path to a # stable system that hasn't been updated for one year. Ulrich
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sun, Sep 18, 2011 at 10:56 AM, Zac Medico zmed...@gentoo.org wrote: On 09/17/2011 08:47 PM, Donnie Berkholz wrote: On 14:06 Fri 16 Sep , Zac Medico wrote: Bumping the EAPI of the root profiles/eapi file would be a different matter, since it applies to the whole repository. If you want to version bump that repository-level EAPI, then you need to wait until at least 6 months after supporting package managers have been available in stable. So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 now? Yes, it's feasible. As a consequence, we may get some complaints from users who haven't upgraded during the last six months. I don't see any features in EAPI 3 and 4 that are useful for the profiles. However, a bump to EAPI 2 (or at least 1) would be *extremely* beneficial, and cause much less chaos. Speaking with my GNOME hat, it will be *extremely* useful for slot-masking GNOME packages. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sun, 18 Sep 2011 14:54:56 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: I don't see any features in EAPI 3 and 4 that are useful for the profiles. However, a bump to EAPI 2 (or at least 1) would be *extremely* beneficial, and cause much less chaos. Speaking with my GNOME hat, it will be *extremely* useful for slot-masking GNOME packages. If that route is taken, I'd recommend 1 rather than 2, for the simple reason that if 2 is introduced to profiles, we need to have a very careful discussion about the meanings of use dependencies in profile files. For example, people might think they can start masking cat/pkg[flag]. Is this a replacement for package.use.mask or does it mean something else? I have a sneaking suspicion that if there's not a policy saying no use deps in profiles then people will start trying to use them for all kinds of horrible hacks that would be better being fixed properly. -- Ciaran McCreesh signature.asc Description: PGP signature
proposal for cross-compie support in EAPI-5, was: Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
Thomas Sachau schrieb:
Tomáš Chvátal schrieb:
Start collecting ideas for EAPI5.
1) USE-flag based support to cross-compile packages (mostly implemented in
multilib-portage)
let me extend this a bit, first the reasoning behind it:
For amd64 users, there is sometimes the issue, that they need 32bit libs for
certain packages (e.g.
wine or many binary-only packages). Currently, they only get them prepackaged
in binary form with
the emul-linux-x86-* packages. But those packages have a few issues (list does
not have to be complete):
-they only contain a limited set of 32bit packages
-they are precompiled, so the user cannot define his own flags
-they have to be manually maintained and updated
So the idea was to add the ability to compile 32bit packages with support from
the package manager,
so there is no need for additional packages to maintain. After this was
originally implemented, it
was further extended to allow cross-compilation for other targets, not only
limited to 32bit packages.
The basic way, how this should work:
First, there is the check, if the current setup is prepared for
cross-compilation, for this, the
content of the MULTILIB_ABIS var is checked. If it has more than 1 (space
seperated) value, those
values are taken and converted into USE flags in the format of
multilib_abi_$ABI.
In the case of current amd64 multilib profile, which i will take as base for my
examples, this means
2 additional USE flags: multilib_abi_amd64 and multilib_abi_x86.
Those USE flags are internally USE_EXPANDed, so the output after the normal USE
flags is in the form
of this: MULTILIB_ABI=amd64 -x86
This way, the user is able to define the target ABIs for each package
independently from global
settings.
During dependency calculation, every dependency gets additional USE deps for
every target ABI, in
this example: category/package[multilib_abi_amd64?,multilib_abi_x86?].
This ensures, that the required dependencies also have the needed 32bit
libs/binaries for the
requested package.
Before the pkg_setup phase is executed, the environment is setup for the first
target ABI (in this
example: amd64), to make it short, i will just copy the current code from
multilib-portage for this:
# Set the CHOST native first so that we pick up the native
# toolchain and not a cross-compiler by accident #202811.
export CHOST=$(get_abi_var CHOST ${DEFAULT_ABI})
export AS=$(tc-getPROG AS as)
export CC=$(tc-getPROG CC gcc)
export CXX=$(tc-getPROG CXX g++)
export FC=$(tc-getPROG FC gfortran)
export CHOST=$(get_abi_var CHOST $1)
export CBUILD=$(get_abi_var CHOST $1)
export CDEFINE=$(get_abi_var CDEFINE $1)
export CCASFLAGS=${CCASFLAGS:-${CFLAGS}} $(get_abi_var CFLAGS)
export CFLAGS=${CFLAGS} $(get_abi_var CFLAGS)
export CPPFLAGS=${CPPFLAGS} $(get_abi_var CPPFLAGS)
export CXXFLAGS=${CXXFLAGS} $(get_abi_var CFLAGS)
export FCFLAGS=${FCFLAGS} $(get_abi_var CFLAGS)
export FFLAGS=${FFLAGS} $(get_abi_var CFLAGS)
export ASFLAGS=${ASFLAGS} $(get_abi_var ASFLAGS)
export LDFLAGS=${LDFLAGS} $(get_abi_var CFLAGS)
local LIBDIR=$(get_abi_var LIBDIR $1)
export PKG_CONFIG_PATH=/usr/${LIBDIR}/pkgconfig
if [[ ${ABI} != ${DEFAULT_ABI} ]]; then
[[ -z ${CCACHE_DIR} ]] || export
CCACHE_DIR=${CCACHE_DIR}/${ABI}
fi
After this, all phases until after src_install are executed as usual.
After src_install, there are some checks:
If there is another target ABI, the install dir is checked for possible
abi-specific files (headers,
libs, binaries).
If both conditions are true, the current install dir is saved in a different
location, everything
cleaned up and the package manager starts again at the preparation step for the
target ABI before
pkg_setup. This is done until all target ABIs have been done.
Now comes the merging step: For each target ABI, the installed files get moved
back to the original
install location with 2 exceptions:
-if the headers differ between the target ABIs, they get installed into
abi-specific subdirectories
and the original header file becomes a wrapper file, which includes the
abi-specific header file
depending on the current environenment.
-if there are binaries (and this step is not restricted), those get moved into
their original
location, but with an abi-specific appendix, the original file is replaced by a
symlink to an
abi-wrapper, which executes the abi-specific binary depending on the current
environment.
After this is done, following phases are executed. the pkg_* phases after
src_install are looped
over all currently enabled target ABIs. This ensures, that abi-specific
commands are executed for
every target ABI.
Differences, options and other things with current multilib-portage
implementation:
The binary wrapping in current multilib-portage is only happening, if the
package is
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18-09-2011 09:33, Ciaran McCreesh wrote: On Sun, 18 Sep 2011 14:54:56 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: I don't see any features in EAPI 3 and 4 that are useful for the profiles. However, a bump to EAPI 2 (or at least 1) would be *extremely* beneficial, and cause much less chaos. Speaking with my GNOME hat, it will be *extremely* useful for slot-masking GNOME packages. If that route is taken, I'd recommend 1 rather than 2, for the simple reason that if 2 is introduced to profiles, we need to have a very careful discussion about the meanings of use dependencies in profile files. For example, people might think they can start masking cat/pkg[flag]. Is this a replacement for package.use.mask or does it mean something else? I have a sneaking suspicion that if there's not a policy saying no use deps in profiles then people will start trying to use them for all kinds of horrible hacks that would be better being fixed properly. What other meanings could it have? What would be the problem with moving the package use flag masks from package.use.mask to package.mask? As we're talking about updating profiles EAPI, what do we need to get to be able to mask use flags for the stable tree, but not the testing tree? Also, should we get back to the discussion of decoupling keywords from ebuilds and move them to profiles? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOdf4yAAoJEC8ZTXQF1qEPmxsQAKX/rqRhF9cnekdaVZK9oPSA wd9GxDoof2zkUgf0UM+HH0ACzZ7cIznodK32gY+J0waBAucmq/Dn3xbrY2wrpJS7 130HqbKB+jyX+7SaT1DYdwdDJ4hAvdgAG0Vhnq6xF2lsvFPYsuq6irMzK8lXdeID qEUMQ8+7RtrotilVyeIuiSUUp+I8Z6vdhKbqmAYf91/UP5BOFvtleF6vVimtj4HA q+i6ELpExrIvH1zWgIJ9k0oyL+LNWCnOiajT4dy7qdy73wVy+8LLA2+nntLIbhdv X4HSm9wHvhKsdB1OCub0rh+WFH4gBb6CoZtqSWHuzLEEXzClXsym0XxjqBu8slaj F8+e04jTF1zO9GchDlOvAWJroOP9hsKlSJg+bbvnk4Dat72OPKA1zJf/R9XurNkn 4MWPgY7TCYbpIB2hSPHsmQ7rnxz8sj+pgDZqY8MNpqLl7XGITSMhp7Krq0yS2MOP mkI5ZvhVkx9eqvM2MRe0KCKsC7r1U/2DSgkS+YlRmUvD2ts08miY5Ce2bVS4OWP3 5Wr5mVBJTlMMrN0NUX0LVtt3yuDV6voVeyxEI3iCMRAfYde34ddpFJ3e5x8q7bAA aldoJ8383J6RWhx7dBhnLgQ/zQm94E4g9o9sJW5sYwcfZ4qOh+SQbnuI7HVxEj2e vuvrabJqE2RsjHfJcW+y =axJ6 -END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sun, 18 Sep 2011 10:33:32 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 18 Sep 2011 14:54:56 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: I don't see any features in EAPI 3 and 4 that are useful for the profiles. However, a bump to EAPI 2 (or at least 1) would be *extremely* beneficial, and cause much less chaos. Speaking with my GNOME hat, it will be *extremely* useful for slot-masking GNOME packages. If that route is taken, I'd recommend 1 rather than 2, for the simple reason that if 2 is introduced to profiles, we need to have a very careful discussion about the meanings of use dependencies in profile files. For example, people might think they can start masking cat/pkg[flag]. Is this a replacement for package.use.mask or does it mean something else? I have a sneaking suspicion that if there's not a policy saying no use deps in profiles then people will start trying to use them for all kinds of horrible hacks that would be better being fixed properly. Do you consider masking USE flags in repositories a 'horrible hack'? Because that's the use I see for newer-EAPI profile. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sun, 18 Sep 2011 16:47:14 +0200 Michał Górny mgo...@gentoo.org wrote: For example, people might think they can start masking cat/pkg[flag]. Is this a replacement for package.use.mask or does it mean something else? I have a sneaking suspicion that if there's not a policy saying no use deps in profiles then people will start trying to use them for all kinds of horrible hacks that would be better being fixed properly. Do you consider masking USE flags in repositories a 'horrible hack'? Because that's the use I see for newer-EAPI profile. I'm not entirely sure what you mean by that. Which is pretty much the problem: it's really not clear what use dependencies in profile files mean. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 18 Sep 2011 14:20:34 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: For example, people might think they can start masking cat/pkg[flag]. Is this a replacement for package.use.mask or does it mean something else? I have a sneaking suspicion that if there's not a policy saying no use deps in profiles then people will start trying to use them for all kinds of horrible hacks that would be better being fixed properly. What other meanings could it have? What would be the problem with moving the package use flag masks from package.use.mask to package.mask? Well, the behaviour is likely going to be different. Unless a package manager adds in special behaviour to cover this, use dependencies in package.mask will prevent an upgrade whereas package.use.mask allows the upgrade but disables the flag. I think that example illustrates perfectly why we don't want to just blindly enable EAPI 2 in profiles. As we're talking about updating profiles EAPI, what do we need to get to be able to mask use flags for the stable tree, but not the testing tree? Every time this has come up, the conclusion has been it's a horrible idea from a QA perspective, since it would mean that testing something in ~arch would be different to testing it in arch. Also, should we get back to the discussion of decoupling keywords from ebuilds and move them to profiles? So far as I'm aware, not using CVS is a prerequisite for this. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk52FT0ACgkQ96zL6DUtXhHrKACfRYXquFwMl3quPb7vmUwoSsO5 FFsAnjrYE9kJRMBoInAY1cWe6XiyAJ4m =TQGA -END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sep 18, 2011 12:05 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 18 Sep 2011 14:20:34 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: As we're talking about updating profiles EAPI, what do we need to get to be able to mask use flags for the stable tree, but not the testing tree? Every time this has come up, the conclusion has been it's a horrible idea from a QA perspective, since it would mean that testing something in ~arch would be different to testing it in arch. Isn't that already true from a dependency standpoint? I do see your point, but the concept of rolling out a risky flag to the brave first does make sense. I think the biggest issue with ~arch is when things get deployed there for a very long time before hitting stable. That applies to libraries, baselayout-2, or flags. Things shouldn't go to ~arch unless we have a plan to make them stable (excepting one-offs). Rich
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sun, Sep 18, 2011 at 7:50 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: As we're talking about updating profiles EAPI, what do we need to get to be able to mask use flags for the stable tree, but not the testing tree? What's wrong with versioned masking of use-flags? The fact that they have to be constantly maintained is actually a good thing since it means that people will keep revisiting the mask with every STABLEREQ, and it won't get outdated and forgotten. Also, should we get back to the discussion of decoupling keywords from ebuilds and move them to profiles? What's the use-case for this? What is the new proposed format to store the keywords? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On 09/18/2011 07:20 AM, Jorge Manuel B. S. Vicetto wrote: What other meanings could it have? What would be the problem with moving the package use flag masks from package.use.mask to package.mask? As Ciaran said, these two kinds of masks give two very different behaviors that are not interchangeable in current dependency resolvers. If you make make them interchangeable, then you take away a kind of granularity that is provided by having them separate, and you also have to change how the dependency resolvers handle them in all package managers (and repoman too). As we're talking about updating profiles EAPI, what do we need to get to be able to mask use flags for the stable tree, but not the testing tree? Also, should we get back to the discussion of decoupling keywords from ebuilds and move them to profiles? As I have said before [1], I would suggest to create separate profiles for stable and unstable, and add separate entries to profiles.desc so that repoman can check them separately. [1] http://archives.gentoo.org/gentoo-dev/msg_32b26e8f276201923a8fb05dc83d8832.xml -- Thanks, Zac
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On 14:06 Fri 16 Sep , Zac Medico wrote: Bumping the EAPI of the root profiles/eapi file would be a different matter, since it applies to the whole repository. If you want to version bump that repository-level EAPI, then you need to wait until at least 6 months after supporting package managers have been available in stable. So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 now? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpT74nMsKtpS.pgp Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On 09/17/2011 08:47 PM, Donnie Berkholz wrote: On 14:06 Fri 16 Sep , Zac Medico wrote: Bumping the EAPI of the root profiles/eapi file would be a different matter, since it applies to the whole repository. If you want to version bump that repository-level EAPI, then you need to wait until at least 6 months after supporting package managers have been available in stable. So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 now? Yes, it's feasible. As a consequence, we may get some complaints from users who haven't upgraded during the last six months. For users like these, we could take a snapshot of the tree before the EAPI is bumped, and archive it so they can use it to update their package manager to a version that supports the new EAPI. -- Thanks, Zac
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On 09/15/2011 05:20 PM, Arfrever Frehtes Taifersar Arahesis wrote:
2011-09-16 01:54:44 Brian Harring napisał(a):
On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar
Arahesis wrote:
2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
On Thu, 15 Sep 2011 09:35:21 +0200
Michał Górny mgo...@gentoo.org wrote:
Could you point me to at least a single program not supporting dots
in useflags? My quick check shows that all PMs handle them well, quse
and euse as well.
Hrm, it's rather disappointing that they're accepted everywhere. That
really shouldn't happen... My excuse for Paludis is that I never quite
got around to passing in additional flags to validation of names, and
dots are legal in exheres-0
There is no reason for Gentoo to be worse than Exherbo and not allow dots
in USE flags.
Seriously Arfrever, drop the rhetoric here, and go fix the profile
compatibility issue.
I suggest to support files with -${EAPI} suffix.
Examples:
profiles/package.mask-5
profiles/use.desc-5
profiles/base/package.mask-5
profiles/base/package.use-5
profiles/base/package.use.force-5
profiles/base/package.use.mask-5
profiles/base/use.force-5
profiles/base/use.mask-5
profiles/desc/python_abis.desc-5
I'd prefer not to use separate files per eapi, since that effectively
gives you multiple profiles that behave differently depending on the
supported EAPI of the package manager.
As an alternative, I suggest to use the 'eapi' file to specify the EAPI
for all files in the directory. If you want to roll out EAPI 5 profiles
sooner, then you can fork a new base profile that only supports EAPI 5
or later, and base new profiles off of that. Bumping the EAPI of the
root profiles/eapi file would be a different matter, since it applies to
the whole repository. If you want to version bump that repository-level
EAPI, then you need to wait until at least 6 months after supporting
package managers have been available in stable.
--
Thanks,
Zac
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Wed, 7 Sep 2011 23:53:50 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 07 Sep 2011 18:47:17 -0400 Aaron W. Swenson titanof...@gentoo.org wrote: I second the allowing dots in USE flag names. Definitely would be helpful for declaring version related USE flags. You know you won't be able to mention such flags in the base profile, right? At least not for a year or more, until the base profile's eapi can be set to something other than 0. Could you point me to at least a single program not supporting dots in useflags? My quick check shows that all PMs handle them well, quse and euse as well. The only backwards-compat issue I see is repoman complaining. But this can be changed easily. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 15 Sep 2011 09:35:21 +0200 Michał Górny mgo...@gentoo.org wrote: Could you point me to at least a single program not supporting dots in useflags? My quick check shows that all PMs handle them well, quse and euse as well. Hrm, it's rather disappointing that they're accepted everywhere. That really shouldn't happen... My excuse for Paludis is that I never quite got around to passing in additional flags to validation of names, and dots are legal in exheres-0, so they're currently accepted everywhere. I'll probably get around to fixing that at some point. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 15 Sep 2011 08:55:08 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 Sep 2011 09:35:21 +0200 Michał Górny mgo...@gentoo.org wrote: Could you point me to at least a single program not supporting dots in useflags? My quick check shows that all PMs handle them well, quse and euse as well. Hrm, it's rather disappointing that they're accepted everywhere. That really shouldn't happen... My excuse for Paludis is that I never quite got around to passing in additional flags to validation of names, and dots are legal in exheres-0, so they're currently accepted everywhere. And may I remind you that lately you deliberately changed PMS for all EAPIs to satisfy invalid paludis behavior? And you knew that it caused actual breakages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, Sep 15, 2011 at 09:35:21AM +0200, Micha?? G??rny wrote: On Wed, 7 Sep 2011 23:53:50 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 07 Sep 2011 18:47:17 -0400 Aaron W. Swenson titanof...@gentoo.org wrote: I second the allowing dots in USE flag names. Definitely would be helpful for declaring version related USE flags. You know you won't be able to mention such flags in the base profile, right? At least not for a year or more, until the base profile's eapi can be set to something other than 0. Could you point me to at least a single program not supporting dots in useflags? My quick check shows that all PMs handle them well, quse and euse as well. pmerge -pv sys-apps/portage[it.validate.atom.use.flags.just.not.make.conf] ~harring
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
2011-09-15 09:55:08 Ciaran McCreesh napisał(a): On Thu, 15 Sep 2011 09:35:21 +0200 Michał Górny mgo...@gentoo.org wrote: Could you point me to at least a single program not supporting dots in useflags? My quick check shows that all PMs handle them well, quse and euse as well. Hrm, it's rather disappointing that they're accepted everywhere. That really shouldn't happen... My excuse for Paludis is that I never quite got around to passing in additional flags to validation of names, and dots are legal in exheres-0 There is no reason for Gentoo to be worse than Exherbo and not allow dots in USE flags. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis wrote: 2011-09-15 09:55:08 Ciaran McCreesh napisał(a): On Thu, 15 Sep 2011 09:35:21 +0200 Michał Górny mgo...@gentoo.org wrote: Could you point me to at least a single program not supporting dots in useflags? My quick check shows that all PMs handle them well, quse and euse as well. Hrm, it's rather disappointing that they're accepted everywhere. That really shouldn't happen... My excuse for Paludis is that I never quite got around to passing in additional flags to validation of names, and dots are legal in exheres-0 There is no reason for Gentoo to be worse than Exherbo and not allow dots in USE flags. Seriously Arfrever, drop the rhetoric here, and go fix the profile compatibility issue. Everytime you bring up dot's in use, you ignore compatibility, and every damn time it gets brought up I keep having to repeat this. It's not productive and this has repeated for at least a year now. People who want this need to sort the compat issue rather than sticking their heads in the sand. ~brian
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
2011-09-16 01:54:44 Brian Harring napisał(a):
On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
On Thu, 15 Sep 2011 09:35:21 +0200
Michał Górny mgo...@gentoo.org wrote:
Could you point me to at least a single program not supporting dots
in useflags? My quick check shows that all PMs handle them well, quse
and euse as well.
Hrm, it's rather disappointing that they're accepted everywhere. That
really shouldn't happen... My excuse for Paludis is that I never quite
got around to passing in additional flags to validation of names, and
dots are legal in exheres-0
There is no reason for Gentoo to be worse than Exherbo and not allow dots
in USE flags.
Seriously Arfrever, drop the rhetoric here, and go fix the profile
compatibility issue.
I suggest to support files with -${EAPI} suffix.
Examples:
profiles/package.mask-5
profiles/use.desc-5
profiles/base/package.mask-5
profiles/base/package.use-5
profiles/base/package.use.force-5
profiles/base/package.use.mask-5
profiles/base/use.force-5
profiles/base/use.mask-5
profiles/desc/python_abis.desc-5
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
Tomáš Chvátal schrieb: Start collecting ideas for EAPI5. 1) USE-flag based support to cross-compile packages (mostly implemented in multilib-portage) 2) USE-flag based support to install for different slots (e.g. python, ruby or php) 3) (internal) USE-flag based support to re-install packages (replacement for revdep-rebuild/@preserved-rebuild) The order of the list is also in the order of how much of it is already implemented and could be easily drafted. The first one already has a working implementation, so might just need some smaller adjustments. The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to have a general framework for all slotted languages, so there is no need to re-implement the same for every language. The third one is mostly an idea, where packages requiring a rebuild of depending packages define a specific var (SLOT or some new one line ABI_SLOT, which needs to be updated, when depending packages need to be rebuild), so that whenever this var is updated, all depending packages have to be rebuild. This probably needs a bit more of discussion and thinking to get it properly drafted. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, Sep 8, 2011 at 10:03 AM, Thomas Sachau to...@gentoo.org wrote: Tomáš Chvátal schrieb: Start collecting ideas for EAPI5. 1) USE-flag based support to cross-compile packages (mostly implemented in multilib-portage) 2) USE-flag based support to install for different slots (e.g. python, ruby or php) 3) (internal) USE-flag based support to re-install packages (replacement for revdep-rebuild/@preserved-rebuild) The order of the list is also in the order of how much of it is already implemented and could be easily drafted. The first one already has a working implementation, so might just need some smaller adjustments. The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to have a general framework for all slotted languages, so there is no need to re-implement the same for every language. The third one is mostly an idea, where packages requiring a rebuild of depending packages define a specific var (SLOT or some new one line ABI_SLOT, which needs to be updated, when depending packages need to be rebuild), so that whenever this var is updated, all depending packages have to be rebuild. This probably needs a bit more of discussion and thinking to get it properly drafted. I thought the usual problem behind this wasn't so much the implementation but instead was getting maintainers to change the ABI_SLOT on a library would be difficult. Either they would do it too often (unnecessarily) or they would not do it enough (so we would still need revdep friends.)
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 08 Sep 2011 19:03:56 +0200, Thomas Sachau to...@gentoo.org wrote: Tomáš Chvátal schrieb: Start collecting ideas for EAPI5. 2) USE-flag based support to install for different slots (e.g. python, ruby or php) The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to have a general framework for all slotted languages, so there is no need to re-implement the same for every language. I would definately like to see something around this. It feels silly that slotted languages and its package behave almost the same, but different enough for it to be quite annoying for the end users. Also those packagers who have to deal with language bindings towards multiple slotted languages experience quite a lot of pain because of how differently this behaviour is implemented in the various eclasses. -- Ole Markus
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
2011-09-08 19:03:56 Thomas Sachau napisał(a): Tomáš Chvátal schrieb: Start collecting ideas for EAPI5. 2) USE-flag based support to install for different slots (e.g. python, ruby or php) The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to have a general framework for all slotted languages, so there is no need to re-implement the same for every language. It's better to have it implemented in eclasses. E.g. Python scripts need to be specially handled (python_merge_intermediate_installation_images() renames them (so that their names include Python ABI), calls python_convert_shebangs() if they don't have appropriate shebangs, and calls python_generate_wrapper_scripts() to create appropriate wrapper scripts). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 8 Sep 2011 20:10:23 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: 2011-09-08 19:03:56 Thomas Sachau napisał(a): Tomáš Chvátal schrieb: Start collecting ideas for EAPI5. 2) USE-flag based support to install for different slots (e.g. python, ruby or php) The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to have a general framework for all slotted languages, so there is no need to re-implement the same for every language. It's better to have it implemented in eclasses. E.g. Python scripts need to be specially handled (python_merge_intermediate_installation_images() renames them (so that their names include Python ABI), calls python_convert_shebangs() if they don't have appropriate shebangs, and calls python_generate_wrapper_scripts() to create appropriate wrapper scripts). Eclasses itself can't handle this in really useful manner. PM needs to provide us with a nice ability to handle all that. Otherwise, we end up with more and more ugly hacks and needless rebuilds. The point in ABI slots should be to let PM build each slot independently and handle cross-slot depends. IOW, if I build one package for multiple python ABIs, I don't need every other python package built for all of them. Same goes for multilib -- I need 32-bit libs for wine, not for the whole system. And I want them being built when I start needing them, without requiring a rebuild of half of the system. And with separate USEflags. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 8 Sep 2011 20:35:48 +0200 Michał Górny mgo...@gentoo.org wrote: PM needs to provide us with a nice ability to handle all that. I've yet to see a complete, detailed, accurate description of what all that really is. It's a bit hard to come up with an EAPI solution when we don't know what the problem is. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 8 Sep 2011 19:33:03 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 8 Sep 2011 20:35:48 +0200 Michał Górny mgo...@gentoo.org wrote: PM needs to provide us with a nice ability to handle all that. I've yet to see a complete, detailed, accurate description of what all that really is. It's a bit hard to come up with an EAPI solution when we don't know what the problem is. I wasn't the person suggesting this for EAPI5. I was rather pointing out we're not ready for that. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thursday, September 08, 2011 14:10:23 Arfrever Frehtes Taifersar Arahesis wrote: 2011-09-08 19:03:56 Thomas Sachau napisał(a): Tomáš Chvátal schrieb: Start collecting ideas for EAPI5. 2) USE-flag based support to install for different slots (e.g. python, ruby or php) The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to have a general framework for all slotted languages, so there is no need to re-implement the same for every language. It's better to have it implemented in eclasses. E.g. Python scripts need to be specially handled (python_merge_intermediate_installation_images() renames them (so that their names include Python ABI), calls python_convert_shebangs() if they don't have appropriate shebangs, and calls python_generate_wrapper_scripts() to create appropriate wrapper scripts). the EAPI still needs updating so that SLOT can contain USE flag based values. like USE=multislot that binutils/gcc has carried forever. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
Resending as i sent it from gmail instead of google acc so it didn't hit the list. -- Přeposlaná zpráva -- Od: Tomáš Chvátal tomas.chva...@gmail.com Datum: 5. září 2011 18:08 Předmět: Re: [gentoo-dev-announce] Call for items for September 13 council meeting Komu: gentoo-dev@lists.gentoo.org Start collecting ideas for EAPI5. I myself would like PATCHES array to be default in src_prepare phase and some solution for runtime optional deps, Instead of elog in postinst something like Recommended from rpm. Cheers Tom
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
Ack.. both makes definitely sense. -- Přeposlaná zpráva -- Od: Tomáš Chvátal tomas.chva...@gmail.com Datum: 5. září 2011 18:08 Předmět: Re: [gentoo-dev-announce] Call for items for September 13 council meeting Komu: gentoo-dev@lists.gentoo.org Start collecting ideas for EAPI5. I myself would like PATCHES array to be default in src_prepare phase and some solution for runtime optional deps, Instead of elog in postinst something like Recommended from rpm. Cheers Tom
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Wed, 7 Sep 2011, Tomáš Chvátal wrote: Start collecting ideas for EAPI5. I suggest that EAPI 5 should include the two features that have been omitted from EAPI 4 [1,2]. Apart from this, I think we should be more careful for the next EAPI, in order to avoid such long delays as we had with EAPI 4. One possible solution would be to only accept features where a preliminary implementation in Portage is available. I myself would like PATCHES array to be default in src_prepare phase and some solution for runtime optional deps, Instead of elog in postinst something like Recommended from rpm. Looks reasonable (if an implementation is ready). Although I don't understand how it is related to rpm. Ulrich [1] http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=9d2b8ee57bf3be941cfdfe13650952d91b9edfdc [2] http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=409fccc10861c361f37a959195d7581a5c376dd9
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
2011/9/7 Ulrich Mueller u...@gentoo.org: On Wed, 7 Sep 2011, Tomáš Chvátal wrote: Start collecting ideas for EAPI5. I suggest that EAPI 5 should include the two features that have been omitted from EAPI 4 [1,2]. Apart from this, I think we should be more careful for the next EAPI, in order to avoid such long delays as we had with EAPI 4. One possible solution would be to only accept features where a preliminary implementation in Portage is available. Agreed the wait last time was really bad. I myself would like PATCHES array to be default in src_prepare phase and some solution for runtime optional deps, Instead of elog in postinst something like Recommended from rpm. Looks reasonable (if an implementation is ready). Although I don't understand how it is related to rpm. Well the patches code is in base eclass. For Recommended it works like this: blabla.spec Recommended: xf86-video-ati zypper in blabla ... You might consider installing these additional packages: xf86-video-ati It for sure needs more thinking as this is just basic idea. It might even take into account that if you install the recommended patckage with oneshot it should not be depcleaned unless all recommending packages are gone too, and so on.
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Wed, 7 Sep 2011 16:27:01 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Well the patches code is in base eclass. Then you should first consider moving epatch to PMS. I'd honestly prefer going the other way. For Recommended it works like this: blabla.spec Recommended: xf86-video-ati zypper in blabla ... You might consider installing these additional packages: xf86-video-ati It for sure needs more thinking as this is just basic idea. It might even take into account that if you install the recommended patckage with oneshot it should not be depcleaned unless all recommending packages are gone too, and so on. It had some thinking, and ended up in no agreement. There's really no reason to hack up the spec to replace one hack with another. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Wed, 7 Sep 2011 11:07:21 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Start collecting ideas for EAPI5. I'd highlight the following bugs: 311795 - [Future EAPI] Allow dots in USE flag names 373377 - [Future EAPI] Remove IMAGE (deprecated already) -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Wed, 7 Sep 2011 11:07:21 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Start collecting ideas for EAPI5. http://archives.gentoo.org/gentoo-pms/msg_dfef93f8d6bc6684d4dc9793563b4fdf.xml was my list. There are also various bits of lousy wording in PMS that I'd like to get cleared up over an EAPI (such as what exactly a self block does). The problem is, we can't get a reliable answer to can this be implemented in Portage quickly?... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/07/2011 11:48 AM, Michał Górny wrote: On Wed, 7 Sep 2011 11:07:21 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Start collecting ideas for EAPI5. I'd highlight the following bugs: 311795 - [Future EAPI] Allow dots in USE flag names 373377 - [Future EAPI] Remove IMAGE (deprecated already) I second the allowing dots in USE flag names. Definitely would be helpful for declaring version related USE flags. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk5n9HUACgkQCOhwUhu5AEk+RQEAomdG51DXzVT3CSRjGGVtoRNI GFfmapur0VavmIj8jHIA/2sDQBbaTKKDYx4TVfQ5p2eRnw4PaSMsLnHKUgSC0HJl =kAaj -END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 07 Sep 2011 18:47:17 -0400 Aaron W. Swenson titanof...@gentoo.org wrote: I second the allowing dots in USE flag names. Definitely would be helpful for declaring version related USE flags. You know you won't be able to mention such flags in the base profile, right? At least not for a year or more, until the base profile's eapi can be set to something other than 0. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5n9f4ACgkQ96zL6DUtXhFtdQCfY5bc8r9E0HAGYFxcI/5ozEjb 5c0AoJjY9BhzCNiWty3i1jHZm13CbNGz =cymm -END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Wed, Sep 07, 2011 at 11:53:50PM +0100, Ciaran McCreesh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 07 Sep 2011 18:47:17 -0400 Aaron W. Swenson titanof...@gentoo.org wrote: I second the allowing dots in USE flag names. Definitely would be helpful for declaring version related USE flags. You know you won't be able to mention such flags in the base profile, right? At least not for a year or more, until the base profile's eapi can be set to something other than 0. use.desc and use.local.desc don't have EAPI versioning either; as such they're eapi=0 till versioning is introduced (and then wait till the support is deployed far enough to avoid breaking people). Meaning, just the same as I said on this bug... this isn't viable, and frankly it's not really a deal breaker lacking it. It can be worked around. If folks want it, they're going to need to sort out all of the backward compatibility issues *prior* to trying to shove it into eapi. ~harring
