Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 517658 - [Future EAPI] Add TDEPEND to avoid circular dependencies with FEATURES="test"
Summary: [Future EAPI] Add TDEPEND to avoid circular dependencies with FEATURES="test"
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2014-07-21 08:31 UTC by Manuel Rüger (RETIRED)
Modified: 2020-04-11 20:20 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Rüger (RETIRED) gentoo-dev 2014-07-21 08:31:52 UTC
This idea tries to solve two problems:

a) Some packages can only run tests successfully when being already installed.

b) Some packages create circular dependencies because they depend on each other to run tests successfully.


Solution for a) with package app-foo/bar:

TDEPEND="app-foo/bar"

PM installs app-foo/bar first, disabling FEATURES="test" and installs it again, enabling FEATURES="test".

Solution for b) with package app-foo/bar which RDEPENDs on app-foo/baz, while app-foo/baz needs app-foo/bar to run tests successfully.

app-foo/bar:
RDEPEND="app-foo/baz"
app-foo/baz:
TDEPEND="app-foo/bar"

PM installs app-foo/baz, installs app-foo/bar, installs and runs tests on app-foo/baz again.



Possible extensions:
- noop non-src_test phases to avoid compilation and installation times (if possible)
- Solve problems like app-foo/baz DEPEND="bar? ( app-foo/bar )" and app-foo/bar DEPEND="baz? ( app-foo/baz )": Add a variable FIDIUSE="bar" (First Install Disabled IUSE), that disables selected USE flags on the first install (and enforces a second install). This no longer needs TDEPEND then, just FIDIUSE="test" would do the same.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-07-21 08:38:55 UTC
(In reply to Manuel Rüger from comment #0)
> This idea tries to solve two problems:
> 
> a) Some packages can only run tests successfully when being already
> installed.

Which is non-sense since they will run the tests against the previous version when upgrading...

> b) Some packages create circular dependencies because they depend on each
> other to run tests successfully.

This doesn't justify adding another variable.

> Solution for a) with package app-foo/bar:
> 
> TDEPEND="app-foo/bar"
> 
> PM installs app-foo/bar first, disabling FEATURES="test" and installs it
> again, enabling FEATURES="test".
>
> Solution for b) with package app-foo/bar which RDEPENDs on app-foo/baz,
> while app-foo/baz needs app-foo/bar to run tests successfully.
> 
> app-foo/bar:
> RDEPEND="app-foo/baz"
> app-foo/baz:
> TDEPEND="app-foo/bar"
> 
> PM installs app-foo/baz, installs app-foo/bar, installs and runs tests on
> app-foo/baz again.

Both of this can be done with current 'test?'.
Comment 2 Manuel Rüger (RETIRED) gentoo-dev 2014-07-21 09:03:32 UTC
(In reply to Michał Górny from comment #1)
> (In reply to Manuel Rüger from comment #0)
> > This idea tries to solve two problems:
> > 
> > a) Some packages can only run tests successfully when being already
> > installed.
> 
> Which is non-sense since they will run the tests against the previous
> version when upgrading...
> 

You can always do things like TDEPEND="=app-foo/bar-${PV}". I agree, that packages should avoid this behaviour and need to be fixed.

> > b) Some packages create circular dependencies because they depend on each
> > other to run tests successfully.
> 
> This doesn't justify adding another variable.
> 
> > Solution for a) with package app-foo/bar:
> > 
> > TDEPEND="app-foo/bar"
> > 
> > PM installs app-foo/bar first, disabling FEATURES="test" and installs it
> > again, enabling FEATURES="test".
> >
> > Solution for b) with package app-foo/bar which RDEPENDs on app-foo/baz,
> > while app-foo/baz needs app-foo/bar to run tests successfully.
> > 
> > app-foo/bar:
> > RDEPEND="app-foo/baz"
> > app-foo/baz:
> > TDEPEND="app-foo/bar"
> > 
> > PM installs app-foo/baz, installs app-foo/bar, installs and runs tests on
> > app-foo/baz again.
> 
> Both of this can be done with current 'test?'.

Probobaly I missed that app-foo/baz and app-foo/bar will be installed with disabled tests and then reinstalled afterwards (and run tests). If this is possible today, I'd like to know how you would do that?
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-07-21 09:18:17 UTC
At the moment, this can be done manually by user. If you wish, provide a patch for portage to handle that. Creating another variable that does the same will not make code appear magically.
Comment 4 Manuel Rüger (RETIRED) gentoo-dev 2014-07-21 09:29:12 UTC
I don't see how a PM can detect if tests need to be disabled to avoid circular dependencies. Being explicit using an additional variable is more efficient than backtracking here.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-07-21 10:03:59 UTC
And how is exactly 'DEPEND=test?' different from 'TDEPEND'? It just differs in the name...
Comment 6 Manuel Rüger (RETIRED) gentoo-dev 2014-07-21 10:12:15 UTC
If TDEPEND is defined, PM knows that it has to drop FEATURES="test" on first install.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-07-21 10:37:04 UTC
So if the circular dependency is mutual, e.g. A has TDEPEND on B, and B has TDEPEND on A, portage will never be able to solve it anyway. Unless it figures out that either of the packages is installed... which means we're back to square one since TDEPEND doesn't change a thing.
Comment 8 Manuel Rüger (RETIRED) gentoo-dev 2014-07-21 10:48:29 UTC
If neither package A nor B is installed and you run a command to install A B,
the PM installs A without depending on B and without running tests, B without depending on A and without running tests. After each TDEPEND has been satisfied the PM installs A and runs the tests, installs B and runs the tests.
I don't see the problem here?
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-07-21 10:57:42 UTC
But if PM needs to know whether TDEPEND is satisfied or not... it is no different from exception for DEPEND=test?. So you're steeping the learning curve for no real advantage.

Technicalities aside, I'm not convinced that silently disabling tests is a good idea. If I want tests done, I don't want to have untested packages installed behind my back.

You don't provide any clean strategy for handling test failures following the install. So, you install foo without tests, then try to reinstall it with tests and they fail. But the package is installed already, so the damage is done...
Comment 10 Ciaran McCreesh 2014-07-21 12:12:16 UTC
(In reply to Manuel Rüger from comment #2)
> You can always do things like TDEPEND="=app-foo/bar-${PV}". I agree, that
> packages should avoid this behaviour and need to be fixed.

Won't work if USE flags have been changed.
Comment 11 Pacho Ramos gentoo-dev 2019-12-17 00:30:52 UTC
After the hell I am hitting for upgrading with new python targets 3.8 and lots of python packages with circular deps due to tests... I agree that pretending us to go package per package installing it without tests to unbreak the cycle is terrible. I would even be fine if portage could simply output the whole list of packages that is trying to merge to allow me to simply merge them temporally with USE="-test".

I am spending literally *hours* to solve that (as each time is re-emerging some package without USE test, then re-run emerge -uDN world, then repeat the same again and again)
Comment 12 Pacho Ramos gentoo-dev 2019-12-17 00:32:59 UTC
But I agree that maybe adding a special handling for test? or doc? would be enough over adding one more DEP for each ... :/ 

Also, as the logic to run automatically emerge without the USE and later with the USE enabled would be a bit complicated to implement... simply listing the package atoms that are being pulled would be ok for me to let me merge them manually in one round
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-17 06:41:39 UTC
(In reply to Pacho Ramos from comment #11)
> After the hell I am hitting for upgrading with new python targets 3.8 and
> lots of python packages with circular deps due to tests... I agree that
> pretending us to go package per package installing it without tests to
> unbreak the cycle is terrible. I would even be fine if portage could simply
> output the whole list of packages that is trying to merge to allow me to
> simply merge them temporally with USE="-test".

But it does.  "USE=-test emerge ..." will emerge them all without test deps.  However, that obviously won't solve conflicts that occur purely between test dependencies.
Comment 14 Pacho Ramos gentoo-dev 2019-12-17 08:08:10 UTC
But that will rebuild a different world set, a world set not including the many of the conflicting packages but including lots of non-conflicting ones that, later, will need to get rebuilt again (sometimes bug things like libreoffice). And the worst is that, after rebuilding that, you try to enable tests again globally and you need to, again, resolve many packages manually and one by one.

On the other hand, if portage would simply have an option to list all the packages pulled by a USE="test" emerge -uDN world, we would, indeed, be able to run USE="-test" over that packages
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-17 14:51:47 UTC
I presume you've tried '--with-test-deps y' (possibly with USE=-test) and it didn't resolve the problem in question?
Comment 16 Pacho Ramos gentoo-dev 2019-12-17 21:23:08 UTC
I didn't know that option, the problem is that now I think that I re-emerged all the packages with this conflicts :S

But I will try to remember for the next time thanks... ;)
Comment 17 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-19 08:54:50 UTC
The thing is, I'm all for TDEPEND *if* we can make some meaningful change through it.  Say, if the --with-test-deps were able to treat TDEPEND like PDEPEND, and install all of them without cycles.
Comment 18 Kent Fredric (IRC: kent\n) gentoo-dev 2019-12-21 02:49:15 UTC
One advantage of approach in bug #697914 is that it doesn't require any changes to PMS to work, so can work with any EAPI.

IME, the current use of USE="test" to gate this is adequate information to direct a package manager how to do things.

The only real debate IME is *When* the package manager should do this, as clearly for some people, the default mechanism of allowing packages to be installed without testing, when they've specified FEATURES="test", is undesirable.

So instead of lumping those who want that behaviour, with those who don't want that behaviour, a package-manager feature that toggles between the two seems the best approach.
Comment 19 Kent Fredric (IRC: kent\n) gentoo-dev 2019-12-21 04:53:42 UTC
(In reply to Michał Górny from comment #17)
> The thing is, I'm all for TDEPEND *if* we can make some meaningful change
> through it.  Say, if the --with-test-deps were able to treat TDEPEND like
> PDEPEND, and install all of them without cycles.

Actually, I suspect portage can do that today with minimal patching.

But as-is, --with-test-deps doesn't introduce real cycles as long as the dependencies themselves aren't USE="test"

As much as I *like* the semantic clarity of an explicit TDEPEND, as far as the data is concerned, the data to make this decision is already present, as long as portage has the capacity to control whether the USE="test" flag is actually activated when building the package.

Portage would be effectively violating PMS in some regards to do this, but not in a way that has any meaningful impact.
Comment 20 Kent Fredric (IRC: kent\n) gentoo-dev 2019-12-21 05:00:35 UTC
And something that bothers me with TDEPEND as a proposal is you still need a mechanism to determine "is testing going to actually happen for this package", so you still need the capacity in the package to do `if use test ; then ... `

( For instance, I have many packages where I have to conditionally patch things based on whether or not tests will run, as if tests aren't getting run, not patching the sources can result in build-time excessive dependencies that aren't actually used for anything, due to limitations in upstream tooling )

If TDEPEND supplants DEPEND=test? , then by proxy, it removes the need for IUSE="test"

But without IUSE="test", you have no mechanism to answer this question.

So a TDEPEND proposal without specifying how packages query "are tests getting run" is an incomplete proposal.
Comment 21 Zac Medico gentoo-dev 2019-12-27 20:38:09 UTC
(In reply to Michał Górny from comment #17)
> The thing is, I'm all for TDEPEND *if* we can make some meaningful change
> through it.  Say, if the --with-test-deps were able to treat TDEPEND like
> PDEPEND, and install all of them without cycles.

The --with-test-deps PDEPEND-like behavior is implemented now (bug 703348), but only for USE=-test since otherwise it would violate PMS.

(In reply to Pacho Ramos from bug 703348 comment #6)
> Could it also allow circular deps when USE=test *AND* FEATURES="-test" ?
> Otherwise I need to rebuild monsters as webkit-gtk two times :/

It's a reasonable idea, but PMS does not specify any special relationship between FEATURES=-test and USE=test, so it would technically violate PMS. TDEPEND would solve this problem by eliminating all interaction with USE=test.
Comment 22 Zac Medico gentoo-dev 2020-04-11 20:20:36 UTC
Realistically, we may need TDEPEND and TBDEPEND.