Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 705602 - Allow package.env to change PKGDIR
Summary: Allow package.env to change PKGDIR
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-16 21:57 UTC by throwd
Modified: 2022-07-28 05:06 UTC (History)
2 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 throwd 2020-01-16 21:57:57 UTC
Currently there is now way to specify if a package, or overlay should use an alternative PKGDIR when building BINPKGs. 

Attempting to set PKGDIR= within /etc/portage/env/alt_pkgdir with an appropriate entry in /etc/portage/packages.env/ doesn't change the PKGDIR that the built package will be built into. 

There is no documentation at https://wiki.gentoo.org/wiki//etc/portage/package.env that would indicate that some environment variables are unable to be modified. 

Here is a scenario that is being negatively effected by being unable to alter PKGDIR. 

A user wants to build ship packages, and debug packages. These packages are to be built on the same system, and use packages.env to alter the various flags for debug builds. These packages are then distributed to other machines that are used for testing purposes. 

An existing ship binpkg will be overwrriten when a debug version of the same pkg is built, or vice versa. This is expected behavior since the resulting package will have the same binpkg name as the ship version. 

The feature binpkg-multi-instance isn't a suitable alternative, as it's possible for the ship version ship and debug versions of the package to have the same USE flags.
Comment 1 Zac Medico gentoo-dev 2020-01-20 21:49:13 UTC
(In reply to throwd from comment #0)
> The feature binpkg-multi-instance isn't a suitable alternative, as it's
> possible for the ship version ship and debug versions of the package to have
> the same USE flags.

Can you elaborate about why binpkg-multi-instance isn't suitable? With binpkg-multi-instance, you are able to have multiple instances of the same package version with same or different USE flags.
Comment 2 throwd 2020-01-21 05:37:36 UTC
The reason I believe binpkg-multi-instance to be unsuitable is the consuming client can't differentiate between the multiple packages when they have the same USE flags, but different' CFLAGS.

With different use flags, a client has --binpkg-respect-use to ensure they get the package that they want. There is no --binpkg-respect-cflags alternative to ensure the client gets the build they want. 

Enabling the change of PKGDIR with package.env I could easily set an entire overlay that builds with specific CFLAGS into it's own PKGDIR. Then the client could specify that overlay to install from, and would look for the binpkgs in a particular PKGDIR.
Comment 3 Zac Medico gentoo-dev 2020-01-21 06:11:04 UTC
(In reply to throwd from comment #2)
> Enabling the change of PKGDIR with package.env I could easily set an entire
> overlay that builds with specific CFLAGS into it's own PKGDIR. Then the
> client could specify that overlay to install from, and would look for the
> binpkgs in a particular PKGDIR.

I'm trying to understand your workflow, so can you give an example of how you would build packages for multiple clients? How do you get two different builds of the same package with different CFLAGS, does this mean that you change your package.env settings in between builds?
Comment 4 throwd 2020-01-21 15:46:13 UTC
My setup is as following.

I have overlays for the different ways I'd want to build a package by altering the CFLAGS. For example I want to have a debug overlay.

The debug overlay will have symlinks to existing ebuilds that I want to build in this way. For example within the debug overlay I could have a symlink to /usr/portage/net-analyzer/wireshark. 

I then create a debug_cflags file within /etc/portage/env. This will set cflags to something like 
CFLAGS=-g -O0 -fsanitize=address

I create an entry within /etc/portage/package.env/debug that will set all packages from the debug overlay to build with these Cflags
*/*::debug debug_cflags

Now when building I have a simple workaround I'm currently using. I create a wrapper for emerge for each overlay that would later CFLAGS and simply set PKGDIR on the command line. 

emerge-debug
    PKGDIR=/path/to/debug/binpkgs emerge "${@}"

This will put my debug packages in the PKGDIR that I want, but I have more than 1 overlay that I build with different CFLAGS and I think it's messy to build wrappers for each overlay. 

Now that the package is built, and debug and ship binpkgs are separated a client can now consume the packages. 

Most of my clients will simply use the ship binpkg. They receive the packages via a NFS share that is on the network. Within this share I have multiple BINPKGs for multiple architectures, and within those architectures different PKGDIRs for different CFLAGS. 

/exports/packages
  - x86_64/ - Default Ship
     - debug/
     - static/

  - x86/ - Default Ship
      - debug/
      - static/

   - aarch64/ Default Ship
     - debug/ 
     - static/

When I configured the machines I would set the PKGDIR in make.conf to point to the ship packages. Now for my clients to install one of these debug packages for their system they would have to use a wrapper that will specify the proper PKGDIR to get it from.

emerge-debug: 
    PKGDIR=/exports/packages/x86_64/debug emerge "${@}"

That's my workflow. By allowing me to specify PKGDIR in either /etc/portage/env or within /etc/portage/repos.conf/ My machines don't need to wrap emerge to set the PKGDIR for a given overlay.