Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 638196 - Provide means to set env in profiles like /etc/portage/package.env
Summary: Provide means to set env in profiles like /etc/portage/package.env
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 909194 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-11-20 03:41 UTC by William L. Thomson Jr.
Modified: 2024-03-22 08:07 UTC (History)
3 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 William L. Thomson Jr. 2017-11-20 03:41:50 UTC
It would be very beneficial to be able to set per package environment stuff via a profile like that can be done via /etc/portage/package.env. I have a need to modify some package features within a custom profile vs per system. I am presently unable to via profile.bashrc in a custom profile. Not sure if there is a way via profiles or not, seems presently there is not.

Example
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/profile.bashrc

Thank you for consideration of this request!
Comment 1 William L. Thomson Jr. 2017-12-30 18:56:36 UTC
For the time being I had to create a package for such. I could use something like ansible for the same, but it becomes cumbersome for file renames, removals, etc. This does a better job in tracking changes.

https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/app-portage/package-env-no-bin/package-env-no-bin-0.1.ebuild

I still feel something should be done globally so packages can mark themselves as non-binpkgs. Something that should not be put into a binary unless a user overrides something. I do not think licenses allow redistribution of such. Like say oracle-jdk-bin, android-studio and others.

It can also heavily slow down merging as it takes some time to make the binary tarball. Things like oracle-jdk-bin install much faster when not making a binary of a binary :)
Comment 2 Zac Medico gentoo-dev 2017-12-31 05:54:51 UTC
(In reply to William L. Thomson Jr. from comment #1)
> I still feel something should be done globally so packages can mark
> themselves as non-binpkgs. Something that should not be put into a binary
> unless a user overrides something. I do not think licenses allow
> redistribution of such. Like say oracle-jdk-bin, android-studio and others.

For the sake of consistency, I feel like people binary packages should be created by default for everything. Even for the RESTRICT=bindist case, it's perfectly fine to distribute these packages on a private network within one's home or company.

The RESTRICT=fetch thing is obviously annoying, and having the binary package allows clients on a private network to avoid having to deal with it.
Comment 3 William L. Thomson Jr. 2018-01-03 03:41:43 UTC
(In reply to Zac Medico from comment #2)
> (In reply to William L. Thomson Jr. from comment #1)
> > I still feel something should be done globally so packages can mark
> > themselves as non-binpkgs. Something that should not be put into a binary
> > unless a user overrides something. I do not think licenses allow
> > redistribution of such. Like say oracle-jdk-bin, android-studio and others.
> 
> For the sake of consistency, I feel like people binary packages should be
> created by default for everything. Even for the RESTRICT=bindist case, it's
> perfectly fine to distribute these packages on a private network within
> one's home or company.

One of my dislikes aside from time to make. It wastes space on the portage server. I guess you can delete the binary tarball keeping the user made ones. But then you get one per revision, while the package sources may not be changing.

It happens that a fair amount of -bin packages are quite large. Having multiple copies times multiple versions times revisions can eat up a considerable amount of space. Which may not be valid for packages cleaning. Not having bins cuts that out by 2 fold, no bin of a bin, and no bin of any revisions. Just the original source.

> The RESTRICT=fetch thing is obviously annoying, and having the binary
> package allows clients on a private network to avoid having to deal with it.

That is not really relevant to my gripe. Granted some -bins are fetch restricted. Not sure any from source stuff is fetch restricted. That maybe exclusively bins.

I just in general see little benefit in making bins of bins. I get there could be use within corporate etc. The time to install is moot. Mostly if you went to ensure no changes. But then other ways for the same based on ebuild manifest, etc.

Another case that is not even -bin is like Linux kernel sources. That is a source installed package. I do not see much benefit in making a new tarball of those sources :)
Comment 4 William L. Thomson Jr. 2018-01-04 18:48:46 UTC
(In reply to Zac Medico from comment #2)
> 
> The RESTRICT=fetch thing is obviously annoying, and having the binary
> package allows clients on a private network to avoid having to deal with it.

Is that not a breach of what makes it fetch restricted to begin with?

Take say oracle-jdk-bin. I do not think you can legally redistribute that in another binary format. Even within the same company. I would have to do further research. I think it is ok to copy the downloaded fetch restricted tarball. But distributing a re-made one to get around fetch restriction. I am not sure that would be legal. Likely need a legal opinion to know for sure.

Gentoo mirrors cannot mirror fetch restricted stuff. I think the same rules that prevent Gentoo mirrors from mirror fetch restricted binaries. Would apply to any remade tarball being distributed internally. A home/end user maybe ok but not sure about a company.
Comment 5 Mike Gilbert gentoo-dev 2018-01-04 19:09:04 UTC
(In reply to William L. Thomson Jr. from comment #4)
> (In reply to Zac Medico from comment #2)
> > 
> > The RESTRICT=fetch thing is obviously annoying, and having the binary
> > package allows clients on a private network to avoid having to deal with it.
> 
> Is that not a breach of what makes it fetch restricted to begin with?

My 2 cents: I don't think enforcing the law on behalf of the end user is a primary purpose behind RESTRICT="fetch" or RESTRICT="mirror".

RESTRICT="fetch" is mainly used when the sources cannot be fetched without some interactive process on the part of the end user.

RESTRICT="mirror" is mainly there to prevent people hosting Gentoo mirrors from accidentally redistributing source files without a license allowing them to do so. It's not necessarily there to prevent users from doing it.

We generally leave the end user free to violate the law, which may be different depending on where they live.
Comment 6 Zac Medico gentoo-dev 2018-01-04 21:15:34 UTC
Also that RESTRICT=fetch is ignored when fetching from any "local" mirrors defined in /etc/portage/mirrors. As Mike said, we don't make any assumptions about what laws may or may not be applicable on private networks.
Comment 7 William L. Thomson Jr. 2018-01-06 23:59:03 UTC
(In reply to Mike Gilbert from comment #5)
>
> RESTRICT="fetch" is mainly used when the sources cannot be fetched without
> some interactive process on the part of the end user.

Which I believe in most cases is accepting some license or other download terms, registration, etc. There maybe some that are not, but I believe the vast majority at least any I have seen or used were such.

> We generally leave the end user free to violate the law, which may be
> different depending on where they live.

I agree on options, even to do what one should not. I was thinking the default should not allow such. Enabling binpkg on fetch restricted may by default violate some license/law by default. I guess that could be considered user done since binpkg is not enabled by default. I would not think that to be the same as the user circumventing some warning etc to violate license, etc.

Just the same I think I would be nice to have some means for the packager/ebuild author/maintainer to be able to mark one as not by default. Like marking USE flags enabled by default for sane/reasonable defaults. Or ones that do not breach licenses, bindist, etc.
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-03-22 08:07:07 UTC
*** Bug 909194 has been marked as a duplicate of this bug. ***