Re: [gentoo-dev] [PATCH] Add section about defining "Test Dependencies"
On Fri, 24 Aug 2018 14:24:06 -0400 Mike Gilbert wrote: > --- > general-concepts/dependencies/text.xml | 38 ++ > 1 file changed, 38 insertions(+) > > diff --git a/general-concepts/dependencies/text.xml > b/general-concepts/dependencies/text.xml > index 2f10380..64be9dc 100644 > --- a/general-concepts/dependencies/text.xml > +++ b/general-concepts/dependencies/text.xml > @@ -578,6 +578,44 @@ valid. > > > > + > +Test Dependencies > + > + > + > +Packages often have optional dependencies that are needed only when running > +tests. These should be specified in DEPEND behind a USE flag. Often, the > +'test' USE flag is used for this purpose. > + > + > + > +Since testing will likely fail when test dependencies are not installed, the > +test phase should be disabled in this case. This may be accomplished via USE > +conditionals in the RESTRICT variable. > + > + > + > +If other optional features must be enabled/disabled when testing, > REQUIRED_USE > +may be set to express this. > + > + > + > +# Define some USE flags > +IUSE="debug test" > + > +# Disable test phase when test USE flag is disabled > +RESTRICT="!test? ( test )" I do not understand why we need this useless code. If test USE flag is disabled, tests must be disabled as well. It is PM's job and there is no need to put this obvious stuff into each ebuild with tests and extra deps. I see no reason to support running src_test() with USE="-test". > +# Running tests requires 'foo' to be installed > +DEPEND="test? ( dev-util/foo )" > + > +# Require debug support when tests are enabled > +REQUIRED_USE="test? ( debug )" > + > + > + > + > + > > > Best regards, Andrew Savchenko pgpQJ7D4TfKlS.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Sat, 2018-08-25 at 01:14 +0200, Francesco Riosa wrote:
> Il 24/08/18 19:08, Mike Gilbert ha scritto:
> > On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric wrote:
> > > On Fri, 24 Aug 2018 10:27:01 -0400
> > > Mike Gilbert wrote:
> > >
> > > > If you want to define behavior that can be relied upon in ebuilds, it
> > > > should be specified in PMS. PMS does not define any meaning for the
> > > > "test" USE flag.
> > >
> > > We should eschew idealism about how the world *should* behave, and avoid
> > > making portage a steaming garbage heap in order to comply with a
> > > terrible PMS specification of a heavily used feature.
> >
> > Portage still works just fine for most people who would enable
> > FEATURES=test. Stop exaggerating.
> >
>
> People enabling FEATURES=test on most but not all packages had some
> troubles and they need to disable them in both package.{env,use}
> I'd like to have a flag to reinstate the previous portage behaviour, but
> that's probably too late
>
That was a bug in Portage and AFAIK it has been fixed. It would be nice
if people didn't add extra hacks to workaround bugs that no longer
exist.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
Il giorno sab 25 ago 2018 alle ore 01:45 Zac Medico ha
scritto:
> On 08/24/2018 04:14 PM, Francesco Riosa wrote:
> >
> > Il 24/08/18 19:08, Mike Gilbert ha scritto:
> >> On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric
> wrote:
> >>> On Fri, 24 Aug 2018 10:27:01 -0400
> >>> Mike Gilbert wrote:
> >>>
> If you want to define behavior that can be relied upon in ebuilds, it
> should be specified in PMS. PMS does not define any meaning for the
> "test" USE flag.
> >>> We should eschew idealism about how the world *should* behave, and
> avoid
> >>> making portage a steaming garbage heap in order to comply with a
> >>> terrible PMS specification of a heavily used feature.
> >> Portage still works just fine for most people who would enable
> >> FEATURES=test. Stop exaggerating.
> >>
> > People enabling FEATURES=test on most but not all packages had some
> > troubles and they need to disable them in both package.{env,use}
> > I'd like to have a flag to reinstate the previous portage behaviour, but
> > that's probably too late
>
> Would a FEATURES setting that implies RESTRICT="!test? ( test )" for all
> ebuilds do what you want?
>
"want" is too much,
but it would have been pleasant to have something to keep portage
dependancies working as before.
"testrespectuse" or "usetestrespectfeatures" come to mind or another
command line option.
> --
> Thanks,
> Zac
>
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On 08/24/2018 04:14 PM, Francesco Riosa wrote:
>
> Il 24/08/18 19:08, Mike Gilbert ha scritto:
>> On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric wrote:
>>> On Fri, 24 Aug 2018 10:27:01 -0400
>>> Mike Gilbert wrote:
>>>
If you want to define behavior that can be relied upon in ebuilds, it
should be specified in PMS. PMS does not define any meaning for the
"test" USE flag.
>>> We should eschew idealism about how the world *should* behave, and avoid
>>> making portage a steaming garbage heap in order to comply with a
>>> terrible PMS specification of a heavily used feature.
>> Portage still works just fine for most people who would enable
>> FEATURES=test. Stop exaggerating.
>>
> People enabling FEATURES=test on most but not all packages had some
> troubles and they need to disable them in both package.{env,use}
> I'd like to have a flag to reinstate the previous portage behaviour, but
> that's probably too late
Would a FEATURES setting that implies RESTRICT="!test? ( test )" for all
ebuilds do what you want?
--
Thanks,
Zac
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
Il 24/08/18 19:08, Mike Gilbert ha scritto:
> On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric wrote:
>> On Fri, 24 Aug 2018 10:27:01 -0400
>> Mike Gilbert wrote:
>>
>>> If you want to define behavior that can be relied upon in ebuilds, it
>>> should be specified in PMS. PMS does not define any meaning for the
>>> "test" USE flag.
>> We should eschew idealism about how the world *should* behave, and avoid
>> making portage a steaming garbage heap in order to comply with a
>> terrible PMS specification of a heavily used feature.
> Portage still works just fine for most people who would enable
> FEATURES=test. Stop exaggerating.
>
People enabling FEATURES=test on most but not all packages had some
troubles and they need to disable them in both package.{env,use}
I'd like to have a flag to reinstate the previous portage behaviour, but
that's probably too late
[gentoo-dev] [RFC] New global USE flag: gtk-doc
USE=doc has a very overloaded meaning. Meson doesn't ship pre-generated gtk-docs like autotools did, thus developers writing GLib/GTK+ apps may want to keep them around, as libraries move from autotools to meson. gtk-doc is integrated into various IDEs and standalone devhelp viewer, giving a concrete case when one might want to globally enable this (if using those IDEs until they don't have online gtk-doc support that's still in the works, offline developer docs, or matching system versions docs on purpose). Per-package USE=doc is rather inconvenient to manage. Suggested description for global gtk-doc USE: Build and install gtk-doc based developer documentation Longer version idea: Build and install gtk-doc based developer documentation for dev- util/devhelp, IDE and offline use As the "Build" in the description suggests, this is only for when a generation is needed. In practice this means that it shouldn't be used for autotools based builds from tarballs, where the gtk-doc is already shipped - for those you just want a dev-util/gtk-doc-am build dep, which will make gtkdoc-rebase available that the standard gtk-doc autotools rules call to make the pre-generated docs pretty much equal to what you'd get from regenerating (mainly local offline links). In those aforementioned autotools cases, it's often questionable to have a USE flag (doc) at all for this when using proper tarballs. Most GNOME libraries have converted to using meson, thus building them is necessary to keep local developer docs available and thus keep IDE integration useful. Just always building gtk-doc would be distasteful to some, hence this global USE flag proposal. There will be dozens of consumers as I bump libraries for GNOME 3.26 and even more so 3.28 and 3.30 soon enough afterwards. Some are already there (including some not from GNOME), which currently use USE=doc for this. Instead of supporting disted tarballs with meson, they plan to do aforementioned online docs support for the API docs integrations, but I haven't heard about any progress on that, plus offline use use case will remain anyways. Mart signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] Add section about defining "Test Dependencies"
--- general-concepts/dependencies/text.xml | 38 ++ 1 file changed, 38 insertions(+) diff --git a/general-concepts/dependencies/text.xml b/general-concepts/dependencies/text.xml index 2f10380..64be9dc 100644 --- a/general-concepts/dependencies/text.xml +++ b/general-concepts/dependencies/text.xml @@ -578,6 +578,44 @@ valid. + +Test Dependencies + + + +Packages often have optional dependencies that are needed only when running +tests. These should be specified in DEPEND behind a USE flag. Often, the +'test' USE flag is used for this purpose. + + + +Since testing will likely fail when test dependencies are not installed, the +test phase should be disabled in this case. This may be accomplished via USE +conditionals in the RESTRICT variable. + + + +If other optional features must be enabled/disabled when testing, REQUIRED_USE +may be set to express this. + + + +# Define some USE flags +IUSE="debug test" + +# Disable test phase when test USE flag is disabled +RESTRICT="!test? ( test )" + +# Running tests requires 'foo' to be installed +DEPEND="test? ( dev-util/foo )" + +# Require debug support when tests are enabled +REQUIRED_USE="test? ( debug )" + + + + + -- 2.18.0
Re: [gentoo-dev] [PATCH] eclass: db-use - Update to eapi7-ver
Ühel kenal päeval, R, 24.08.2018 kell 13:28, kirjutas Brian Evans:
> This is a very simple eclass which only calls these functions from
> eclasses:
> ver_cut (EAPI 0-6)
> get_libdir (EAPI 0-5)
> get_libname (ALL EAPI)
>
> I see no little reason to place die statements for unknown EAPIs.
> Just changing the eclasses to better suit the latest EAPI should be
> OK.
I'm unsure about not dying on unknown EAPI, but the rest looks good, as
at least in main tree everything inheriting db-use and using
versionator functions themselves, do properly inherit from versionator
themselves, instead of relying on it via db-use.eclass indirectly.
Not dying on unknown EAPI is not a change in status quo, so I don't
mind it here and for future EAPI-8 I hope we look through the non-
limited eclasses before its introduction.
Mart
> Signed-off-by: Brian Evans
> ---
> eclass/db-use.eclass | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
> index 35f11df034a..83ae94799ca 100644
> --- a/eclass/db-use.eclass
> +++ b/eclass/db-use.eclass
> @@ -1,10 +1,14 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2018 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # This is a common location for functions that aid the use of sys-
> libs/db
> #
> # Bugs: maintainer-nee...@gentoo.org
>
> -inherit versionator multilib
> +# multilib is used for get_libname in all EAPI
> +case "${EAPI:-0}" in
> + 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
> + *) inherit multilib ;;
> +esac
>
> #Convert a version to a db slot
> db_ver_to_slot() {
> @@ -38,7 +42,7 @@ db_findver() {
> fi
>
> PKG="$(best_version $1)"
> - VER="$(get_version_component_range 1-2 "${PKG/*db-/}")"
> + VER="$(ver_cut 1-2 "${PKG/*db-/}")"
> if [ -d "${EPREFIX}"/usr/include/db$(db_ver_to_slot "$VER")
> ]; then
> #einfo "Found db version ${VER}" >&2
> echo -n "$VER"
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] eclass: db-use - Update to eapi7-ver
This is a very simple eclass which only calls these functions from eclasses:
ver_cut (EAPI 0-6)
get_libdir (EAPI 0-5)
get_libname (ALL EAPI)
I see no little reason to place die statements for unknown EAPIs.
Just changing the eclasses to better suit the latest EAPI should be OK.
Signed-off-by: Brian Evans
---
eclass/db-use.eclass | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
index 35f11df034a..83ae94799ca 100644
--- a/eclass/db-use.eclass
+++ b/eclass/db-use.eclass
@@ -1,10 +1,14 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# This is a common location for functions that aid the use of sys-libs/db
#
# Bugs: maintainer-nee...@gentoo.org
-inherit versionator multilib
+# multilib is used for get_libname in all EAPI
+case "${EAPI:-0}" in
+ 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
+ *) inherit multilib ;;
+esac
#Convert a version to a db slot
db_ver_to_slot() {
@@ -38,7 +42,7 @@ db_findver() {
fi
PKG="$(best_version $1)"
- VER="$(get_version_component_range 1-2 "${PKG/*db-/}")"
+ VER="$(ver_cut 1-2 "${PKG/*db-/}")"
if [ -d "${EPREFIX}"/usr/include/db$(db_ver_to_slot "$VER") ]; then
#einfo "Found db version ${VER}" >&2
echo -n "$VER"
--
2.18.0
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Fri, Aug 24, 2018 at 10:45 AM Kent Fredric wrote: > > On Fri, 24 Aug 2018 10:27:01 -0400 > Mike Gilbert wrote: > > > If you want to define behavior that can be relied upon in ebuilds, it > > should be specified in PMS. PMS does not define any meaning for the > > "test" USE flag. > > We should eschew idealism about how the world *should* behave, and avoid > making portage a steaming garbage heap in order to comply with a > terrible PMS specification of a heavily used feature. Portage still works just fine for most people who would enable FEATURES=test. Stop exaggerating.
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Fri, Aug 24, 2018 at 10:37 AM Virgil Dupras wrote: > > On Fri, 24 Aug 2018 10:27:01 -0400 > Mike Gilbert wrote: > > > On Fri, Aug 24, 2018 at 9:23 AM Kent Fredric > > wrote: > > > > > > On Tue, 21 Aug 2018 22:29:29 -0400 > > > Mike Gilbert wrote: > > > > > > > Setting RESTRICT="!test? ( test )" is generally sufficient. > > > > > > But that would require setting that virtually *everything* that has > > > both tests, and required dependencies for tests. > > > > > > Which, in my experience, is practically everything with tests. > > > > > > To the point it seems like that should be the *default* mechanic, > > > not a requirement that everyone pay not to have a randomly broken > > > package. > > > > If you want to define behavior that can be relied upon in ebuilds, it > > should be specified in PMS. PMS does not define any meaning for the > > "test" USE flag. > > > > Which is the easiest path, updating the PMS or adding RESTRICT="!test? > ( test )" to thousands of ebuilds? I don't see how we can realistically > hope for every developer to cooperate in making sure that their ebuilds > behave properly in "USE=-test" situation. Updates to PMS happen infrequently, and generally only introduce behavioral changes in new EAPIs. Adding RESTRICT to ebuilds does not need to happen overnight; setting FEATURES=test still does the right thing for most people, assuming they haven't done something stupid like setting USE=-test in make.conf.
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Fri, 24 Aug 2018 10:27:01 -0400 Mike Gilbert wrote: > If you want to define behavior that can be relied upon in ebuilds, it > should be specified in PMS. PMS does not define any meaning for the > "test" USE flag. We should eschew idealism about how the world *should* behave, and avoid making portage a steaming garbage heap in order to comply with a terrible PMS specification of a heavily used feature. And we should aim to make this design less crappy in some future EAPI. And honestly, I've hated the fact we implement test dependencies via: DEPENDS="test? ( ... )" for so long, its an obvious hack, a terrible one at that. I just haven't seen any good proposals for an alternative, let alone one that got penned up for a future EAPI. But lets not make portage *worse* while we wait for this imaginary future. pgpovyH52bfjJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo i486 support
On Fri, 24 Aug 2018 10:13:42 -0400 Rich Freeman wrote: > I think an exp arch is also overkill. How many packages simply can't > be built for i486? I think a profile+masking makes a lot more sense > than an entire new level of QA that touches every ebuild in the tree > because there might be a few packages that don't work on 25 year old > hardware. In response to other conversations on #gentoo-x86, I think neither are needed any more. All that's needed to target this set is as follows: 1. Focus on the problem in terms of CPU instruction feature sets and memory limitations. 2. Make sure packages that don't work on i586 natively due to lack of instructions, and require adjustment, utilize CPU_FLAGS_X86 to expose this issue, ( eg: sse, mmx, cmov ) 3. Make the CPU_FLAGS_X86 generator tool emits the ideal values when run locally on a given processor. 4. For people targeting minimal should-at-least-work-on-i586/i486 binary images, setting CPU_FLAGS_X86="-*" should be recommended. 5. For people targeting physically ancient platforms with binary media, it might be pertinent to standardize on some sort of USE flag to indicate to applicable packages to optimize for runtime-memory-constrained environments. Or something along those lines. This should avoid all the downsides of new-arches/new profiles, while still allowing ebuilds to introspect and customize themselves as needed. Additionally, the features not being bound to a profile means they can be mixed and matched across profiles, so a memory-constrained environment targeting i686/mips/arm can use the same controls. And users who have, for example, CPUs' *with* the cmov instruction, but an inferior/slow implementation, can opt-out of using that instruction. And then using these tools we can throw minimal-flag-sets and minimal-memory at stage builds. pgpbea3p7AHzh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Fri, 24 Aug 2018 10:27:01 -0400 Mike Gilbert wrote: > On Fri, Aug 24, 2018 at 9:23 AM Kent Fredric > wrote: > > > > On Tue, 21 Aug 2018 22:29:29 -0400 > > Mike Gilbert wrote: > > > > > Setting RESTRICT="!test? ( test )" is generally sufficient. > > > > But that would require setting that virtually *everything* that has > > both tests, and required dependencies for tests. > > > > Which, in my experience, is practically everything with tests. > > > > To the point it seems like that should be the *default* mechanic, > > not a requirement that everyone pay not to have a randomly broken > > package. > > If you want to define behavior that can be relied upon in ebuilds, it > should be specified in PMS. PMS does not define any meaning for the > "test" USE flag. > Which is the easiest path, updating the PMS or adding RESTRICT="!test? ( test )" to thousands of ebuilds? I don't see how we can realistically hope for every developer to cooperate in making sure that their ebuilds behave properly in "USE=-test" situation. Virgil pgpLpPBsPupc0.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Fri, Aug 24, 2018 at 9:23 AM Kent Fredric wrote: > > On Tue, 21 Aug 2018 22:29:29 -0400 > Mike Gilbert wrote: > > > Setting RESTRICT="!test? ( test )" is generally sufficient. > > But that would require setting that virtually *everything* that has > both tests, and required dependencies for tests. > > Which, in my experience, is practically everything with tests. > > To the point it seems like that should be the *default* mechanic, not a > requirement that everyone pay not to have a randomly broken package. If you want to define behavior that can be relied upon in ebuilds, it should be specified in PMS. PMS does not define any meaning for the "test" USE flag.
Re: [gentoo-dev] Gentoo i486 support
On Fri, Aug 24, 2018 at 9:57 AM Mike Gilbert wrote: > > On Fri, Aug 24, 2018 at 9:19 AM Kent Fredric wrote: > > > > On Wed, 22 Aug 2018 07:26:24 -0500 > > Ben Kohler wrote: > > > > > Thoughts? > > > > Is there a good reason we can't have a legacy profile for this? > > > > Or perhaps, a new (exp) arch entirely dedicated to legacy x86? > > Sounds like a lot of work for something that will be used by very few people. > I think an exp arch is also overkill. How many packages simply can't be built for i486? I think a profile+masking makes a lot more sense than an entire new level of QA that touches every ebuild in the tree because there might be a few packages that don't work on 25 year old hardware. -- Rich
Re: [gentoo-dev] Gentoo i486 support
On Fri, Aug 24, 2018 at 9:19 AM Kent Fredric wrote: > > On Wed, 22 Aug 2018 07:26:24 -0500 > Ben Kohler wrote: > > > Thoughts? > > Is there a good reason we can't have a legacy profile for this? > > Or perhaps, a new (exp) arch entirely dedicated to legacy x86? Sounds like a lot of work for something that will be used by very few people.
Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test
On Tue, 21 Aug 2018 22:29:29 -0400 Mike Gilbert wrote: > Setting RESTRICT="!test? ( test )" is generally sufficient. But that would require setting that virtually *everything* that has both tests, and required dependencies for tests. Which, in my experience, is practically everything with tests. To the point it seems like that should be the *default* mechanic, not a requirement that everyone pay not to have a randomly broken package. pgpyjNbNSsTVX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo i486 support
On Wed, 22 Aug 2018 07:26:24 -0500 Ben Kohler wrote: > Thoughts? Is there a good reason we can't have a legacy profile for this? Or perhaps, a new (exp) arch entirely dedicated to legacy x86? The latter would be ideal for ensuring everything we *claim* works on i486 does indeed work there, and making it blatantly obvious what does and doesn't work on i486. And both strategies make it possible to restrict USE graphs to subsets that can only work on i486. The benefit of a new profile for x86 is it would assume everything currently x86 works on i486, and then exceptions can be shot on a case-by-case basis. But that's also the downside, you start with a huge set and play whack-a-mole with it, when ideally, you want to start with a *minimal* working subset and build it out ( and this is where the second option is better ) The arch-approach would also lend itself to compile-time switching in individual packages too. pgpsM5mloWBRq.pgp Description: OpenPGP digital signature
