Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Fri, Mar 27, 2009 at 1:21 AM, Petteri Räty betelge...@gentoo.org wrote: 12) EAPI 3 supports .xz, .tar.xz easy so should be in Easy, so can we also have .xpi unpack support? -- ~Nirbheek Chauhan
Re: [gentoo-dev] Gentoo Council Reminder for March 26
Am Mittwoch, den 25.03.2009, 23:26 + schrieb Ciaran McCreesh:
On Mon, 23 Mar 2009 09:08:37 +0100
Tiziano Müller dev-z...@gentoo.org wrote:
8) EAPI 3 requires doins support for symlinks
Current behaviour is to copy the file the symlink points to, right?
No, current behaviour is undefined for not a file.
from ebuild-helpers/doins:
_doins() {
local mysrc=$1 mydir=$2 cleanup= rval
if [ -L $mysrc ] ; then
cp $mysrc $TMP/2
mysrc=$TMP/2/${mysrc##*/}
cleanup=${mysrc}
fi
[...]
seems like it's copying the target of the symlink.
14) EAPI 3 supports pkg_info on installed packages
you probably mean: uninstalled
Yup. The diff's right, just the commit message that's wrong.
15) USE is stricter in EAPI 3
Proper documentation for IUSE_IMPLICIT/USE_EXPAND_IMPLICIT is needed.
In the PMS draft there's only a reference to section 11.1.1, but in
that section is nothing about it.
I'm still not sure a) whether we want those, b) how exactly they work
or c) whether there's any chance at all of Portage supporting this in
the time we're after.
It completely depends on whether people agree that every USE flag should
be stated in IUSE or not.
20) EAPI 3 has doexample.
Including -r or implicit recursive?
Nope.
Well, I think I want -r then.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Mon, Mar 23, 2009 at 2:08 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 22 Mar 2009 21:18:52 +0100 [snip] 12) EAPI 3 supports .xz, .tar.xz [snip] Could we have EAPI 3 also support extracting .xpi files? Right now ebuilds use xpi_unpack() from mozextension.eclass which is ugly as hell. It seems it should be easy to implement this, and would also go well with the --if-compressed flag to `unpack` -- ~Nirbheek Chauhan
Re: [gentoo-dev] Gentoo Council Reminder for March 26
Am Mittwoch, den 25.03.2009, 23:23 + schrieb Ciaran McCreesh:
On Wed, 25 Mar 2009 23:06:37 +0100
Donnie Berkholz dberkh...@gentoo.org wrote:
9) EAPI 3 bans || ( use? ( ... ) )
What is the suggested replacement? If there's a decent one, sure.
The replacement is to write the deps out correctly. Every single use of
|| ( use? ( ... ) ) in the tree is wrong.
I created bug #262297 for that (with more text, featuring a citation
from a famous non-gentoo-dev ;-).
2) EAPI 3 supports slot operator dependencies
Was this for bug #229521? If so, sure.
Yup. I'm avoiding the term 'multi-slot', though, since that's not what
this is and we're already using multi- in relation to slots for the
non-static SLOT idea.
10) dohard and dosed banned in EAPI 3
I think I missed the reasoning for removing these, particularly
dosed. pybugz didn't see any open bugs.
Portage doesn't merge hardlinks correctly, so dohard is bad.
And there's at least one ebuild in the tree which tries to create a
hardlink across multiple directories and there fails if those are on
separate volumes
And
dosed's been considered deprecated for years.
I've been taught so as well.
11) doinclude, newinclude for EAPI 3
Is installing to /usr/include by default useful for most packages
that want to use this? Or would they /usr/include/${PN}? If you have
to change it often, aren't you just as well off using insinto/doins?
Should there be an includeinto?
I'd be inclined to agree on that one, but people seem to be after more
of these do* things.
Would it be possible that doinclude could also strip +x from
permission bits? I encountered quiet a few packages having +x set for
whatever reason and I had to change that manually.
21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
I'm curious why it isn't global. Seems like it would make sense to
put it near dependencies. Also I could be wrong, but wouldn't you
want to be able to cache this and show smart pretend output, etc?
I think you're misunderstanding what this is for. It's to allow
packages to work out whether they're upgrading / downgrading /
reinstalling / whatever, since Zac broke the devmanual-documented and
PMS-required way of doing it using has_version and refuses to revert it.
... and this also more or less explains why it's only available in some
phases. What must be said here is that REPLACING_VERSIONS and
REPLACED_BY_VERSION in pkg_pretend and pkg_setup must be used carefully
since they may or may not be defined in those phases and there's also no
way to guarantee it (think of binary packages).
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Thu, 26 Mar 2009, Tiziano Müller wrote: Am Mittwoch, den 25.03.2009, 23:23 + schrieb Ciaran McCreesh: 9) EAPI 3 bans || ( use? ( ... ) ) What is the suggested replacement? If there's a decent one, sure. The replacement is to write the deps out correctly. Every single use of || ( use? ( ... ) ) in the tree is wrong. That its use in the tree is often wrong is a non-argument. After all, it's not the package manager's business to educate people. We shouldn't make the syntax of these expressions non-orthogonal without real need. I created bug #262297 for that (with more text, featuring a citation from a famous non-gentoo-dev ;-). Ulrich
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Thu, 26 Mar 2009 08:25:18 +0100 Ulrich Mueller u...@gentoo.org wrote: The replacement is to write the deps out correctly. Every single use of || ( use? ( ... ) ) in the tree is wrong. That its use in the tree is often wrong is a non-argument. After all, it's not the package manager's business to educate people. There's no right way of using it. We shouldn't make the syntax of these expressions non-orthogonal without real need. The behaviour of || ( use? ( ... ) ) is a fluke of an early implementation of Portage that someone picked up on and documented (with incorrect examples). It's *already* special, weird behaviour, and it's special, weird behaviour that can't be used correctly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Thu, Mar 26, 2009 at 7:00 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: The behaviour of || ( use? ( ... ) ) is a fluke of an early implementation of Portage that someone picked up on and documented (with incorrect examples). It's *already* special, weird behaviour, and it's special, weird behaviour that can't be used correctly. I would like to say that I agree. It's special, weird, non-obvious, and easily misunderstood behaviour. Let's chuck it. -- ~Nirbheek Chauhan
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On 12:25 Mon 23 Mar , Robert Buchholz wrote:
On Monday 23 March 2009, Tiziano Müller wrote:
Spec needed. DOCS or no DOCS?
DOCS, and non-empty default value, please [1].
Some eclasses already do this (not base, but others), and if that
default doesn't cover it for you, the function can be overridden.
Concerning the argument of declarative ebuilds vs. bash-oriented ebuilds
brought up by Donnie: Our ebuilds always had declarative parts with an
impact on the PM (e.g. RESTRICT), or on eclasses (WANT_AUTOCONF, or
look at the games eclass).
I think if we stay within sane limits[2], following this paradigm is
going to help developers because more simple cases will be caught by
the default implementation without adding the complexities of having to
know tons of (aka more than one) variables and how they interact.
I probably would have agreed with you a few EAPIs ago where stuff was
more painful. Take a look at this, though -- it doesn't seem so bad to
me in a non-DOCS, EAPI=3 world:
src_install() {
default
dodoc foo bar
}
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgppBqJsPUuHB.pgp
Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
Am Donnerstag, den 26.03.2009, 19:12 +0100 schrieb Donnie Berkholz:
On 12:25 Mon 23 Mar , Robert Buchholz wrote:
On Monday 23 March 2009, Tiziano Müller wrote:
Spec needed. DOCS or no DOCS?
DOCS, and non-empty default value, please [1].
Some eclasses already do this (not base, but others), and if that
default doesn't cover it for you, the function can be overridden.
Concerning the argument of declarative ebuilds vs. bash-oriented ebuilds
brought up by Donnie: Our ebuilds always had declarative parts with an
impact on the PM (e.g. RESTRICT), or on eclasses (WANT_AUTOCONF, or
look at the games eclass).
I think if we stay within sane limits[2], following this paradigm is
going to help developers because more simple cases will be caught by
the default implementation without adding the complexities of having to
know tons of (aka more than one) variables and how they interact.
I probably would have agreed with you a few EAPIs ago where stuff was
more painful. Take a look at this, though -- it doesn't seem so bad to
me in a non-DOCS, EAPI=3 world:
src_install() {
default
dodoc foo bar
}
Well, we can just start with such a default src_install and then change
it in a later EAPI if we see that it would be more useful to have
DOCS=.
But again: eclasses for certain package classes already provide
src_install implementations considering DOCS for installing
documentation. Which shows that some developers think it's useful.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for March 26
Ciaran McCreesh wrote: * what the plan is for Portage implementation of that feature, and the likelihood of it making it We should have someone dedicated to seeing each item implemented. For example someone from the council. Follows a quick list with hopefully no brain farts. In general I consider having pkg_pretend and use dep extensions enough for main features and then we should also implemented all those easily doable little changes. This list might help for those who're scared of git: 1) EAPI 3 has pkg_pretend. critical 2) EAPI 3 supports slot operator dependencies can be dropped 3) EAPI 3 has use dependency defaults critical 4) PROPERTIES, DEFINED_PHASES mandatory in EAPI 3 can be dropped 5) EAPI 3 has a default src_install can be dropped 6) EAPI 3 has controllable compression and docompress critical 7) EAPI 3 has dodoc -r critical 8) EAPI 3 requires doins support for symlinks can be dropped 9) EAPI 3 bans || ( use? ( ... ) ) critical 10) dohard and dosed banned in EAPI 3 can be dropped 11) doinclude, newinclude for EAPI 3 can be dropped 12) EAPI 3 supports .xz, .tar.xz easy so should be in 13) EAPI 3 has more econf arguments easy so should be in 14) EAPI 3 supports pkg_info on installed packages can be dropped 15) USE is stricter in EAPI 3 can be dropped 16) AA, KV gone in EAPI 3 easy so should be in 17) S to WORKDIR fallback conditional for EAPI 3 easy so should be in 18) EAPI 3 has unpack --if-compressed, new src_unpack can be dropped 19) RDEPEND=DEPEND gone in EAPI 3 critical 20) EAPI 3 has doexample. can be dropped 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3 critical 22) EAPI 3 has nonfatal, utilities die can be dropped Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On 21:18 Sun 22 Mar , Donnie Berkholz wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Here's a very simple agenda. I'm at a conference this week, so I'm glad there weren't a ton of topics submitted. =) EAPI-3 update - As usual, I strongly advise people to respond on-list. Please note the recent posts in this thread. Open bugs - I have an update on bug #237381 that I posted to -council a while ago. If no council members have comments on it, I'm going to remove it from draft state. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgp9bRzAh1om6.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On 20:38 Sun 22 Mar , Ciaran McCreesh wrote:
1) EAPI 3 has pkg_pretend.
3) EAPI 3 has use dependency defaults
5) EAPI 3 has a default src_install
15) USE is stricter in EAPI 3
19) RDEPEND=DEPEND gone in EAPI 3
22) EAPI 3 has nonfatal, utilities die
Very Yes. I would really like to see these in portage.
14) EAPI 3 supports pkg_info on installed packages
This should be uninstalled, and yes.
4) PROPERTIES, DEFINED_PHASES mandatory in EAPI 3
6) EAPI 3 has controllable compression and docompress
7) EAPI 3 has dodoc -r
8) EAPI 3 requires doins support for symlinks
12) EAPI 3 supports .xz, .tar.xz
13) EAPI 3 has more econf arguments
16) AA, KV gone in EAPI 3
17) S to WORKDIR fallback conditional for EAPI 3
20) EAPI 3 has doexample.
Sure. Anything here is optional but nice.
9) EAPI 3 bans || ( use? ( ... ) )
What is the suggested replacement? If there's a decent one, sure.
2) EAPI 3 supports slot operator dependencies
Was this for bug #229521? If so, sure.
Now for the ones I'm not so sure about...
10) dohard and dosed banned in EAPI 3
I think I missed the reasoning for removing these, particularly dosed.
pybugz didn't see any open bugs.
11) doinclude, newinclude for EAPI 3
Is installing to /usr/include by default useful for most packages that
want to use this? Or would they /usr/include/${PN}? If you have to
change it often, aren't you just as well off using insinto/doins? Should
there be an includeinto?
18) EAPI 3 has unpack --if-compressed, new src_unpack
Still not convinced about this.
21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
I'm curious why it isn't global. Seems like it would make sense to put
it near dependencies. Also I could be wrong, but wouldn't you want to be
able to cache this and show smart pretend output, etc?
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpsfJw5SQl6P.pgp
Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Wed, 25 Mar 2009 23:06:37 +0100
Donnie Berkholz dberkh...@gentoo.org wrote:
9) EAPI 3 bans || ( use? ( ... ) )
What is the suggested replacement? If there's a decent one, sure.
The replacement is to write the deps out correctly. Every single use of
|| ( use? ( ... ) ) in the tree is wrong.
2) EAPI 3 supports slot operator dependencies
Was this for bug #229521? If so, sure.
Yup. I'm avoiding the term 'multi-slot', though, since that's not what
this is and we're already using multi- in relation to slots for the
non-static SLOT idea.
10) dohard and dosed banned in EAPI 3
I think I missed the reasoning for removing these, particularly
dosed. pybugz didn't see any open bugs.
Portage doesn't merge hardlinks correctly, so dohard is bad. And
dosed's been considered deprecated for years.
11) doinclude, newinclude for EAPI 3
Is installing to /usr/include by default useful for most packages
that want to use this? Or would they /usr/include/${PN}? If you have
to change it often, aren't you just as well off using insinto/doins?
Should there be an includeinto?
I'd be inclined to agree on that one, but people seem to be after more
of these do* things.
21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
I'm curious why it isn't global. Seems like it would make sense to
put it near dependencies. Also I could be wrong, but wouldn't you
want to be able to cache this and show smart pretend output, etc?
I think you're misunderstanding what this is for. It's to allow
packages to work out whether they're upgrading / downgrading /
reinstalling / whatever, since Zac broke the devmanual-documented and
PMS-required way of doing it using has_version and refuses to revert it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Mon, 23 Mar 2009 09:08:37 +0100 Tiziano Müller dev-z...@gentoo.org wrote: 8) EAPI 3 requires doins support for symlinks Current behaviour is to copy the file the symlink points to, right? No, current behaviour is undefined for not a file. 14) EAPI 3 supports pkg_info on installed packages you probably mean: uninstalled Yup. The diff's right, just the commit message that's wrong. 15) USE is stricter in EAPI 3 Proper documentation for IUSE_IMPLICIT/USE_EXPAND_IMPLICIT is needed. In the PMS draft there's only a reference to section 11.1.1, but in that section is nothing about it. I'm still not sure a) whether we want those, b) how exactly they work or c) whether there's any chance at all of Portage supporting this in the time we're after. 20) EAPI 3 has doexample. Including -r or implicit recursive? Nope. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
Am Sonntag, den 22.03.2009, 20:38 + schrieb Ciaran McCreesh: On Sun, 22 Mar 2009 21:18:52 +0100 Donnie Berkholz dberkh...@gentoo.org wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Continuing the whole EAPI 3 thing... http://github.com/ciaranm/pms/tree/eapi-3 is a draft based upon ongoing discussion. There's more or less one commit per new feature. For each feature, I'd like to know: * whether there are any objections to that feature as a candidate for EAPI 3 * what the plan is for Portage implementation of that feature, and the likelihood of it making it I already started to implement small proposals for portage. For some issues some minor structural/architectural have to be made. * whether that feature is considered critical for EAPI 3, or whether it can be dropped if necessary if Portage can't get it implemented within a certain time Also, I'd like to know of any potential omissions. I'd imagine this'd go easier of Council members went through before the meeting and provided individual opinions on each item, and then just discussed any disagreements during the meeting, but whatever's best for you... This list might help for those who're scared of git: 1) EAPI 3 has pkg_pretend. We have to write something here (probably not in PMS but in the devmanual) to make clear what is allowed in pkg_pretend and what not. 2) EAPI 3 supports slot operator dependencies 3) EAPI 3 has use dependency defaults 4) PROPERTIES, DEFINED_PHASES mandatory in EAPI 3 5) EAPI 3 has a default src_install Spec needed. DOCS or no DOCS? 6) EAPI 3 has controllable compression and docompress 7) EAPI 3 has dodoc -r 8) EAPI 3 requires doins support for symlinks Current behaviour is to copy the file the symlink points to, right? Is that behaviour unsafe and should be deprecated completely or do we add a flag turning on the new/the old behaviour? 9) EAPI 3 bans || ( use? ( ... ) ) 10) dohard and dosed banned in EAPI 3 11) doinclude, newinclude for EAPI 3 12) EAPI 3 supports .xz, .tar.xz 13) EAPI 3 has more econf arguments 14) EAPI 3 supports pkg_info on installed packages you probably mean: uninstalled 15) USE is stricter in EAPI 3 Proper documentation for IUSE_IMPLICIT/USE_EXPAND_IMPLICIT is needed. In the PMS draft there's only a reference to section 11.1.1, but in that section is nothing about it. 16) AA, KV gone in EAPI 3 17) S to WORKDIR fallback conditional for EAPI 3 18) EAPI 3 has unpack --if-compressed, new src_unpack 19) RDEPEND=DEPEND gone in EAPI 3 20) EAPI 3 has doexample. Including -r or implicit recursive? 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3 Same thing as for 1) 22) EAPI 3 has nonfatal, utilities die ... and we've got most (if not all) proposals with reasons documented here: http://dev.gentoo.org/~dev-zero/docs/EAPI3.html Cheers, Tiziano signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Monday 23 March 2009, Tiziano Müller wrote: Spec needed. DOCS or no DOCS? DOCS, and non-empty default value, please [1]. Some eclasses already do this (not base, but others), and if that default doesn't cover it for you, the function can be overridden. Concerning the argument of declarative ebuilds vs. bash-oriented ebuilds brought up by Donnie: Our ebuilds always had declarative parts with an impact on the PM (e.g. RESTRICT), or on eclasses (WANT_AUTOCONF, or look at the games eclass). I think if we stay within sane limits[2], following this paradigm is going to help developers because more simple cases will be caught by the default implementation without adding the complexities of having to know tons of (aka more than one) variables and how they interact. Robert [1] As seen here: https://bugs.gentoo.org/show_bug.cgi?id=33544#c17 [2] That is very fuzzy, but we're talking about introducing one variable in one function. Any lower limit would be to disallow. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Sun, 22 Mar 2009 21:18:52 +0100 Donnie Berkholz dberkh...@gentoo.org wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Continuing the whole EAPI 3 thing... http://github.com/ciaranm/pms/tree/eapi-3 is a draft based upon ongoing discussion. There's more or less one commit per new feature. For each feature, I'd like to know: * whether there are any objections to that feature as a candidate for EAPI 3 * what the plan is for Portage implementation of that feature, and the likelihood of it making it * whether that feature is considered critical for EAPI 3, or whether it can be dropped if necessary if Portage can't get it implemented within a certain time Also, I'd like to know of any potential omissions. I'd imagine this'd go easier of Council members went through before the meeting and provided individual opinions on each item, and then just discussed any disagreements during the meeting, but whatever's best for you... This list might help for those who're scared of git: 1) EAPI 3 has pkg_pretend. 2) EAPI 3 supports slot operator dependencies 3) EAPI 3 has use dependency defaults 4) PROPERTIES, DEFINED_PHASES mandatory in EAPI 3 5) EAPI 3 has a default src_install 6) EAPI 3 has controllable compression and docompress 7) EAPI 3 has dodoc -r 8) EAPI 3 requires doins support for symlinks 9) EAPI 3 bans || ( use? ( ... ) ) 10) dohard and dosed banned in EAPI 3 11) doinclude, newinclude for EAPI 3 12) EAPI 3 supports .xz, .tar.xz 13) EAPI 3 has more econf arguments 14) EAPI 3 supports pkg_info on installed packages 15) USE is stricter in EAPI 3 16) AA, KV gone in EAPI 3 17) S to WORKDIR fallback conditional for EAPI 3 18) EAPI 3 has unpack --if-compressed, new src_unpack 19) RDEPEND=DEPEND gone in EAPI 3 20) EAPI 3 has doexample. 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3 22) EAPI 3 has nonfatal, utilities die -- Ciaran McCreesh signature.asc Description: PGP signature
