Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
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
+
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
В Втр, 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.
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
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
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
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-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 17.1.2010 21:38, Petteri Räty napsal(a): 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 ++ should really not be used. Actualy i think since it is just eclass call we could make it not used anywhere in ebuilds, and then mark the functions as deprecated and just return true. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktTd5wACgkQHB6c3gNBRYdHegCfZfD7r0aQUBH+ObWdjNvIDYAt IE4AnjY655N8l7HwY4qZPh4Ms3pY8g4H =5kRF -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
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.
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
On Sunday 17 January 2010 16:12:29 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. you mean you should re-emerge it on your system -mike signature.asc Description: This is a digitally signed message part.
