Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644990 - sys-apps/portage: add mode for binary package installation without regard for ebuild repository or profile state
Summary: sys-apps/portage: add mode for binary package installation without regard for...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Binary packages support (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-18 22:55 UTC by Zac Medico
Modified: 2023-12-10 23:18 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 Zac Medico gentoo-dev 2018-01-18 22:55:45 UTC
Reliance on the ebuild repository and profile is an unnecessary burden when installing binary packages with PORTAGE_BINHOST. It would be convenient to have a mode that simply updates to all of the latest packages available from a binhost, without any regard for the state of the ebuild repository or profile (including package.mask, ACCEPT_KEYWORDS, and ACCEPT_LICENSE).

It's currently possible to achieve this goal by creating a dummy profile to satisfy portage's profile requirements (this was how I discovered bug 640318), but it would be very useful to have an option for emerge to handle this automatically.
Comment 1 Zac Medico gentoo-dev 2018-01-18 23:10:06 UTC
My plan is to essentially generate @world from the packages available on the binhost (which means packages *not* on the binhost are eligible for removal).
Comment 2 Alec Warner (RETIRED) archtester gentoo-dev Security 2018-01-19 15:40:34 UTC
(In reply to Zac Medico from comment #1)
> My plan is to essentially generate @world from the packages available on the
> binhost (which means packages *not* on the binhost are eligible for removal).

I'm trying to follow logically why we would do that though.

To me the binhost is just another package repository (bindb, portdb, vdb, etc.) So sure, it should be possible to run emerge on a host with no portdb (because the bindb is sufficient to enumerate packages, resolve dependencies, and do other operations.) But why would we also tie the world file to the bindb? Other package repositories don't work that way, do they? When I'm using an ebuild repository my world file isn't suddenly filled with every package in the ebuild repository. That would be a bit weird. But it would for a bindb?
Comment 3 Zac Medico gentoo-dev 2018-01-19 17:49:24 UTC
(In reply to Alec Warner from comment #2)
> (In reply to Zac Medico from comment #1)
> > My plan is to essentially generate @world from the packages available on the
> > binhost (which means packages *not* on the binhost are eligible for removal).
> 
> I'm trying to follow logically why we would do that though.
> 
> To me the binhost is just another package repository (bindb, portdb, vdb,
> etc.) So sure, it should be possible to run emerge on a host with no portdb
> (because the bindb is sufficient to enumerate packages, resolve
> dependencies, and do other operations.) But why would we also tie the world
> file to the bindb? Other package repositories don't work that way, do they?
> When I'm using an ebuild repository my world file isn't suddenly filled with
> every package in the ebuild repository. That would be a bit weird. But it
> would for a bindb?

The intention is for this to behave like an in-place cloning system, treating binary packages as a series of deltas that bring the local state into sync with the binhost state. Any deviation from that premise is currently out of scope.

I plan to implement it as a new command that calls emerge. This is necessary, since it will have to do a sys-apps/portage update step if there are any unsupported EAPIs found in the binhost.

This is the currently planned sequence of steps:

1) Detect and apply package moves by comparing binhost packages with installed packages. An in-place package move is detected when a remote package has the same BUILD_TIME and version as an installed package, but it appears to have had a "move" or "slotmove" applied.

2) Update to sys-apps/portage from the binhost if there are any unsupported EAPIs  found.

3) Install all of the latest packages from the binhost.

4) Remove any installed packages that do not exist in the binhost.
Comment 4 Larry the Git Cow gentoo-dev 2018-04-13 01:23:21 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=e767fd990b89bce010b9e9a29c2892eecbf15fa9

commit e767fd990b89bce010b9e9a29c2892eecbf15fa9
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2018-04-13 01:18:10 +0000
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2018-04-13 01:22:23 +0000

    binarytree._update_pkgindex_header: include USE_EXPAND_IMPLICIT vars (bug 644990)
    
    It's useful to have values of USE_EXPAND_IMPLICIT variables in the
    Packages header.
    
    Bug: https://bugs.gentoo.org/644990

 pym/portage/dbapi/bintree.py | 1 +
 1 file changed, 1 insertion(+)}
Comment 5 Jason A. Donenfeld gentoo-dev 2018-04-16 17:36:43 UTC
> My plan is to essentially generate @world from the packages available on the binhost (which means packages *not* on the binhost are eligible for removal).

That means that every node using the binhost will have the same packages? That seems bad. What would be better would to have your mentioned profile-less and portagetree-less emerging, but allow each host to choose which packages it actually wants from the binhost. The most common use of binhosts is to have one powerful system compiling things, and then have various special purpose light weight nodes getting some subset of those packages.

So, rather than populating @world from the binhost, simply populate the entire realm of available packages.
Comment 6 Zac Medico gentoo-dev 2018-04-16 18:38:56 UTC
(In reply to Jason A. Donenfeld from comment #5)
> > My plan is to essentially generate @world from the packages available on the binhost (which means packages *not* on the binhost are eligible for removal).
> 
> That means that every node using the binhost will have the same packages?
> That seems bad.

It's only one use case, it's not supposed to be the right thing for everyone. It doesn't preclude the possibility of supporting other use cases.

> What would be better would to have your mentioned
> profile-less and portagetree-less emerging, but allow each host to choose
> which packages it actually wants from the binhost. The most common use of
> binhosts is to have one powerful system compiling things, and then have
> various special purpose light weight nodes getting some subset of those
> packages.
>
> So, rather than populating @world from the binhost, simply populate the
> entire realm of available packages.

Sure we can easily support that use case as well, using the local world file.