[gentoo-dev] Gentoo Council Reminder for March 26

[gentoo-dev] Gentoo Council Reminder for March 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

Sorry about the delay on this -- I wrote it on a computer that somehow 
fails at sending email and forgot it was in drafts.


This is your friendly reminder! Same bat time (typically the 2nd & 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

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.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting. Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Sun, 22 Mar 2009 21:18:52 +0100
Donnie Berkholz <dberkholz@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

Am Sonntag, den 22.03.2009, 20:38 +0000 schrieb Ciaran McCreesh:
> On Sun, 22 Mar 2009 21:18:52 +0100
> Donnie Berkholz <dberkholz@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


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

On Wed, 25 Mar 2009 23:06:37 +0100
Donnie Berkholz <dberkholz@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

On Mon, 23 Mar 2009 09:08:37 +0100
Tiziano Müller <dev-zero@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

Am Mittwoch, den 25.03.2009, 23:26 +0000 schrieb Ciaran McCreesh:
> On Mon, 23 Mar 2009 09:08:37 +0100
> Tiziano Müller <dev-zero@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.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Nirbheek Chauhan]

On Mon, Mar 23, 2009 at 2:08 AM, Ciaran McCreesh
<ciaran.mccreesh@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

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]

Am Mittwoch, den 25.03.2009, 23:23 +0000 schrieb Ciaran McCreesh:
> On Wed, 25 Mar 2009 23:06:37 +0100
> Donnie Berkholz <dberkholz@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).


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Ulrich Mueller]

>>>>> On Thu, 26 Mar 2009, Tiziano Müller wrote:
> Am Mittwoch, den 25.03.2009, 23:23 +0000 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Thu, 26 Mar 2009 08:25:18 +0100
Ulrich Mueller <ulm@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Nirbheek Chauhan]

On Thu, Mar 26, 2009 at 7:00 PM, Ciaran McCreesh
<ciaran.mccreesh@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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]

On 23:23 Wed 25 Mar     , Ciaran McCreesh wrote:
> On Wed, 25 Mar 2009 23:06:37 +0100
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > > 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.

I like dosed because I've used it many times for the $D-removing 
feature. If there was (is?) an automatic filter at install-time that 
scanned files to remove $D references, that would work for me instead.

> > > 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.

I'm still not convinced this one adds anything significant beyond doins 
by default that it's worth adding. In half the cases 
(/usr/include/$PN/foo.h or anywhere else vs /usr/include/foo.h), you'd 
need to customize its install directory and so effectively are just 
running insinto/doins. Plus it's only useful for ebuilds that have a 
crappy install anyway, so wouldn't we rather fix the build system?

> > > 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.

Ah, I see. This is the first I'd heard about this anywhere (the problem 
or the proposal). So running has_version in setup/preinst and again in 
postinst doesn't do what you'd want anymore?

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Thu, 26 Mar 2009 19:09:17 +0100
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> I like dosed because I've used it many times for the $D-removing 
> feature. If there was (is?) an automatic filter at install-time that 
> scanned files to remove $D references, that would work for me instead.

The fix is to write code that does exactly what you need, rather than
relying upon weird voodoo.

> > 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.
> 
> Ah, I see. This is the first I'd heard about this anywhere (the
> problem or the proposal). So running has_version in setup/preinst and
> again in postinst doesn't do what you'd want anymore?

They don't do what the devmanual says they do these days, yes. Zac
decided to change the version order code a while ago without telling
anyone, and without an EAPI bump. After he was told it broke a load of
ebuilds (and devmanual-described things), which he didn't know about
before he implemented the changes, he went and fixed some, but probably
not all, things relying upon it in a big commit spree...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

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.



[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] Gentoo Council Reminder for March 26

[Nirbheek Chauhan]

On Fri, Mar 27, 2009 at 1:21 AM, Petteri Räty <betelgeuse@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