>>>>> On Sun, 17 Jan 2010, Petteri Räty wrote:

> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause

Agreed.

> so attached is a patch only defines these functions for EAPIs 0, 1
> and 2. Anyone have a reason to keep these around for EAPI 3?

We wouldn't gain much by this, because we still have to go through all
ebuilds using ebeep and epause and change them to EAPI 3.

This would be at least the same amount of work as removing the ebeep
and epause calls from all ebuilds. Why don't we do this instead and
leave the eclass as it is?

There are already enough differences between EAPIs for devs to learn,
and IMHO we shouldn't introduce additional complications such as EAPI
dependent eclass behaviour (except where necessary, e.g. src_prepare).

Ulrich

The proper replacement for such interactive notifications when called in
pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
Thus I'd keep them around until then.

Cheers,
Tiziano

Am Sonntag, den 17.01.2010, 22:38 +0200 schrieb Petteri Räty:
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause so attached is a patch only
> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
> keep these around for EAPI 3? If not I will apply the attached patch.
>
> Regards,
> Petteri

--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

On 01/18/2010 03:02 PM, Tiziano Müller wrote:
> The proper replacement for such interactive notifications when called in
> pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
> Thus I'd keep them around until then.
>
> Cheers,
> Tiziano
>

ebeep or epause don't make your ebuild interactive.

Regards,
Petteri

On 01/18/2010 10:07 AM, Ulrich Mueller wrote:
>>>>>> On Sun, 17 Jan 2010, Petteri Räty wrote:
>
>> With GLEP 42 and proper logging of e* messages I think we shouldn't
>> annoy users any more with ebeep or epause
>
> Agreed.
>
>> so attached is a patch only defines these functions for EAPIs 0, 1
>> and 2. Anyone have a reason to keep these around for EAPI 3?
>
> We wouldn't gain much by this, because we still have to go through all
> ebuilds using ebeep and epause and change them to EAPI 3.
>

This would force people to upgrade when migrating to EAPI 3.

> This would be at least the same amount of work as removing the ebeep
> and epause calls from all ebuilds. Why don't we do this instead and
> leave the eclass as it is?
>

This would make sure no-one uses these even in overlays.

> There are already enough differences between EAPIs for devs to learn,
> and IMHO we shouldn't introduce additional complications such as EAPI
> dependent eclass behaviour (except where necessary, e.g. src_prepare).
>

Yes but as people shouldn't have the need for these there's not that
much to learn here.

Regards,
Petteri

В Втр, 19/01/2010 в 01:22 +0200, Petteri Räty пишет:
> On 01/18/2010 03:02 PM, Tiziano Müller wrote:
> > The proper replacement for such interactive notifications when called in
> > pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
> > Thus I'd keep them around until then.

> ebeep or epause don't make your ebuild interactive.

True, but some ebuilds (e.g. tcpdump) do following:

ewarn "CAUTION !!! CAUTION !!! CAUTION"
ewarn "..."
ewarn "Press Ctrl+C to abort installation"
ebeep 5

And it's better to keep ebeep in such packages until pkg_pretend became
available.

--
Peter.

On 01/19/2010 10:37 AM, Peter Volkov wrote:
> В Втр, 19/01/2010 в 01:22 +0200, Petteri Räty пишет:
>> On 01/18/2010 03:02 PM, Tiziano Müller wrote:
>>> The proper replacement for such interactive notifications when called in
>>> pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
>>> Thus I'd keep them around until then.
>
>> ebeep or epause don't make your ebuild interactive.
>
> True, but some ebuilds (e.g. tcpdump) do following:
>
> ewarn "CAUTION !!! CAUTION !!! CAUTION"
> ewarn "..."
> ewarn "Press Ctrl+C to abort installation"
> ebeep 5
>
> And it's better to keep ebeep in such packages until pkg_pretend became
> available.
>

PROPERTIES="interactive" and really ask the user to proceed if it's
really that important.

Regards,
Petteri

On 01/17/2010 11:12 PM, David Leverton wrote:
> On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
>> With GLEP 42 and proper logging of e* messages I think we shouldn't
>> annoy users any more with ebeep or epause so attached is a patch only
>> defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
>> keep these around for EAPI 3? If not I will apply the attached patch.
>
> The eclass-manpages comments should be updated too.
>

Updated patch. Will commit Wednesday unless there are objections.

Regards,
Petteri
@@ -19,13 +19,15 @@

DESCRIPTION="Based on the ${ECLASS} eclass"

+if has "${EAPI:-0}" 0 1 2; then
+
# @FUNCTION: epause
# @USAGE: [seconds]
# @DESCRIPTION:
# Sleep for the specified number of seconds (default of 5 seconds). Useful when
# printing a message the user should probably be reading and often used in
# conjunction with the ebeep function. If the EPAUSE_IGNORE env var is set,
-# don't wait at all.
+# don't wait at all. Defined in EAPIs 0 1 and 2.
epause() {
[[ -z ${EPAUSE_IGNORE} ]] && sleep ${1:-5}
}
@@ -36,7 +38,7 @@
# Issue the specified number of beeps (default of 5 beeps). Useful when
# printing a message the user should probably be reading and often used in
# conjunction with the epause function. If the EBEEP_IGNORE env var is set,
-# don't beep at all.
+# don't beep at all. Defined in EAPIs 0 1 and 2.
ebeep() {
local n
if [[ -z ${EBEEP_IGNORE} ]] ; then
@@ -49,6 +51,8 @@
fi
}

+fi
+