Re: [gentoo-dev] Package up for grabs: app-arch/unar
On Montag, 9. Dezember 2019 13:03:02 CET Hanno Böck wrote: > It's an archive unpacker written in objective C, which makes it > dependency-heavy (particularly requires gcc compiled with objc). > I originally got interested because it was the only free unpacker > capable of handling modern rar archives. However libarchive does that > these days, so I don't see a strong need for unar any more. Thanks for that hint! app-arch/unar currently seems to be the only free choice for kde-apps/ kdeutils-meta-19.08.3[rar]: rar? ( || ( app-arch/rar app-arch/unrar app-arch/unar ) ) Does anyone know, does kde-apps/ark (for which kdeutils-meta depends on the rar implementations) also support app-arch/libarchive for RAR files? Is any useflag needed to get RAR support in libarchive? If kde-apps/ark does support unpacking RAR files with app-arch/libarchive, could it please be added to that dependency list? Then app-arch/unar could be removed from my system. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote: > See also this related old thread: > https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09 > 211 I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good idea. Generally, all these probably have to distinguish between "support for XYZ" and "use only XYZ", the latter hopefully being the exception, so that the former can take the shorter use-flag. That's what I don't like about the proposal from 2018: Globally enabling USE=gles will have different effects on different packages. That's also what I like about the recent proposal: The flags are more explicit. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
Hello everyone! On Donnerstag, 21. November 2019 04:32:34 CET Haelwenn (lanodan) Monnier wrote: > I noticed for some time that there seems to be two use cases for the > gles[123] family of USE flags in gentoo repo: > 1. enabling support of OpenGL ES, which seems interesting to have for > more runtime choices, probably better usage of the drivers and better > binary-compat support. > 2. switching from OpenGL (so the full API) to Open GL ES (reduced API), > which is an entirely different kind of action as that reduces it quite > significantly but might be useful for machines where the drivers do not > provide (good) OpenGL. I just recently ran into this, putting USE=gles2 in make.conf, thinking that only the first kind of flags existed. Thus I second this proposal. We could start bikeshedding about the naming (e.g. 1. gles2, 2. only-gles2, to keep it shorter), but I don't think that will lead us anywhere and will just delay the execution of this plan. Thanks for proposing this! --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'
On Samstag, 12. Oktober 2019 18:02:28 CEST William Hubbs wrote: > On Sat, Oct 12, 2019 at 01:11:49PM +0200, Michał Górny wrote: > > On Sat, 2019-10-12 at 13:00 +0200, David Seifert wrote: > > > * Some distros have not just merged / and /usr, they > > > > > > have also merged /usr/bin and /usr/sbin. By giving > > > users the choice of merging */bin and */sbin, > > > Gentoo follows suit. > > > > What about the scenario when /bin has been merged with /usr/sbin > > and /sbin with /usr/bin? ;-P > > I also don't see the need for something like this. The idea of the /usr > merge is to have all binaries available in one place, and there really > is not a good justification for separating bin from sbin. Do I read this correctly? USE=-split-usr currently means that /bin, /sbin, / usr/bin and /usr/sbin point to the same directory? If that is not the case, then I agree that users should have the possibility to set it up like this and USE=-split-sbin should be supported. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] C++ standard in ebuilds
On Tuesday, 18 September 2018 16:31:23 CEST Guilherme Amadio wrote:
> On Mon, Sep 17, 2018 at 10:24:48AM -0700, Matt Turner wrote:
> > I don't understand what a potential solution would be.
> >
> > The various projects use -std=c++XXX because that's what their code
> > requires. -std=c++XXX can't generally be changed. If a dependent
> > project is incompatible that's no different than any other case of
> > incompatible dependencies in Gentoo.
> >
> > I think -std=c++XXX discussions before happened because gcc changed
> > the C++ ABI with -std=c++11. I don't think that's particularly
> > relevant here, since as far as I know different -std=c++XXX values
> > don't change the ABI with current gcc.
> >
> > So I guess my understanding is that there isn't a problem different
> > than existing incompatible dependencies, but maybe I have
> > misunderstood you.
>
> My concern is with, say, package foo that depends on both bar and baz,
> and bar and baz support from C++11 to C++17, but must be compiled with
> the same version of the standard so that foo can link against both of
> them without having a broken ABI. I think that depending on bar[c++14],
> or having a similar mechanism to Python to handle "same version of the
> standard" with ${CXXSTD_REQUIRED_USE} or similar in an eclass would be
> nice.
Maybe add a CXXABI USE_EXPAND variable and then handle this case similar to
python-single-r1.eclass packages with CXXABI_COMPAT and CXXABI_USEDEP?
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Tuesday, 24 July 2018 20:57:09 CEST Rich Freeman wrote: > On Tue, Jul 24, 2018 at 2:32 PM Ian Stakenvicius wrote: > > I don't think the process needs to be simplified much more than this; > > each layer above has its purpose. However I do very much want to > > caution on making it more complicated, especially with the addition of > > syntax that allows setting or ignoring useflag state changes in a way > > that will jumble up these layers. > > I think as long as it is a heirarchy it will be straightforward enough. > > If we introduce a ^ operator that unsets a flag, the only question is > how far that propagates down the layers, and into what kinds of > layers: > > Does a profile ^flag undo an IUSE +flag? > Does a make.conf ^flag undo a profile +flag? An IUSE +flag? A > profile flag mask? > Does a package.use ^flag undo a make.conf +flag? A profile +flag, an > IUSE +flag? Etc... I guess the question here is: Is there an official order in which the use settings from the different profiles and config files have to be applied? I think my initial assumption of this order was wrong, USE flags only have two states and indeed it seems that the ^ USE operator is not necessary, because the - operator already serves the same purpose. Thus the other proposal of adding a new server profile and enabling USE=udev for that and the desktop profiles would be sufficient to provide good defaults, but still allow people to not use that profile, if they don't want to. I.e. they could just use the 17.0 release profile and create their own minimal-server profile based on that. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding USE=udev to linux profiles
Am Dienstag, 24. Juli 2018, 19:15:19 CEST schrieb Ian Stakenvicius:
> On 2018-07-21 9:33 a.m., Rich Freeman wrote:
> > On Sat, Jul 21, 2018 at 5:33 AM Zac Medico wrote:
> >> Sure, why not? So ^flag would mean that the flag state propagates from
> >> the settings in IUSE.
> >
> > Presumably this could be overridden in subsequent profiles, or
> > /etc/portage. That is, one profile might set a flag, and another
> > profile could unset it, and then the final one could re-set it.
> >
> >> It's also conceivable that we could add a way for
> >> profiles to modify the effective IUSE defaults, via new operators in
> >> package.use or by introducing a new file such as package.use.default.
> >
> > That makes sense, or the syntax could be available in the ebuild. I
> > imagine the better approach to take would depend on the nature of the
> > incompatibility.
>
> This is getting a little scary as to what is overriding what, within a
> repo.
I also tried to untangle this in my email from Sat, 21 Jul 2018 14:45:12 +
It indeed is a bit confusing, but I think you got it right in your list below:
> Lets take a look at what we -can- do right now:
>
> (a) use flag can be set globally by the repo
> (b) ebuild IUSE can set (and unset?) a flag's state
> (c) make.defaults and package.use from the profile (that generally is
> defined within the gentoo repo) sets/unsets a flag's state
> (d) make.conf sets/unsets a flag's state
> (e) /etc/portage/package.use sets/unsets a flag's state
> (f) {,package.}use.{mask,force} from the profile overrides a-e
> (g) /etc/portage/profile/{,package.}use.{mask,force} overrides f
>
> That's a lot of possible state overriding.
I, too, would hope that at some point later, independently of this discussion,
the algorithm for determining what use flags are active for a certain package
could be simplified.
--Dennis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Saturday, 21 July 2018 11:33:23 CEST Zac Medico wrote:
> On 07/21/2018 12:01 AM, Dennis Schridde wrote:
> > On Friday, 20 July 2018 08:25:05 CEST Michael Orlitzky wrote:
> >> Yes, when you set USE=foo in profile A and USE="-foo" in profile A/B,
> >> the end result is USE="foo -foo" which is the same thing as USE="-foo".
> >> The default portage USE_ORDER makes the profile flags more important
> >> than IUSE defaults, so the USE="-foo" from the profile clobbers any
> >> IUSE="+foo" defaults.
> >>
> >> If no default was set in profile A, then no override would be necessary
> >> in profile A/B, and the resulting USE="" would not override the IUSE
> >> default.
> >
> > It appears to me that the difficulty stems from use flags being tri-state
> > (enabled, disabled, unset), but us having only operators to enable (+) and
> > disable (-) them in make.conf and profiles.
> >
> > What about adding a third operator, e.g. `^`, that resets a use flag to
> > the
> > unset state?
>
> Sure, why not? So ^flag would mean that the flag state propagates from
> the settings in IUSE.
It's important to note that, since profiles are applied hierarchically, this
mechanism would support the following setup:
* profile 3 inherits from 2 inherits from 1
- i.e. 1 is applied before 2 is applied before 3
* profile 1 enables the flag with +use, overriding IUSE defaults
* profile 2 resets the flag with ^use, removing the override
* profile 3 disables the flag with -use, overriding IUSE defaults
1. After applying profile 1, the flag is globally enabled and overrides IUSE
defaults, but can be overridden on a per-package basis
2. After applying profile 2 on top of 1, the flag is unset and IUSE defaults
will be respected again, as well as per-package settings
3. After applying profile 3 on top of 2 and 3, the flag is globally disabled
and overrides IUSE defaults again, but per-package settings could still
override this
This still uses the exact same mechanisms and paths to apply profiles and use
flags, just adding another capability along that path. This would make
profiles more flexible, but not add too much cognitive complexity.
> It's also conceivable that we could add a way for
> profiles to modify the effective IUSE defaults, via new operators in
> package.use or by introducing a new file such as package.use.default.
Currently, for the calculation of the effective use flags of a package, use
flags are applied in the following order (I could not find this algorithm in
PMS, so this is from memory):
1. global use flags from profiles and /etc/portage
1. /etc/portage/make.profile/parent*/make.defaults
2. /etc/portage/make.profile/make.defaults
3. /etc/portage/make.conf
2. IUSE defaults from the package's ebuild
- applied only if use flag still unset
3. per-package overrides from profiles, /etc/portage/profile and /etc/portage
1. /etc/portage/make.profile/parent*/package.use
2. /etc/portage/make.profile/package.use
3. /etc/portage/profile/package.use
4. /etc/portage/package.use
4. globally forced or masked use flags from profiles and /etc/portage/profile
1. /etc/portage/make.profile/parent*/use.{,stable.}{force,mask}
2. /etc/portage/make.profile/use.{,stable.}{force,mask}
3. /etc/portage/profile/use.{,stable.}{force,mask}
5. per-package forced or masked use flags from profiles and /etc/portage/
profile
1. /etc/portage/make.profile/parent*/package.use.{,stable.}{force,mask}
2. /etc/portage/make.profile/package.use.{,stable.}{force,mask}
3. /etc/portage/profile/package.use.{,stable.}{force,mask}
I hope I did not forget anything.
Your suggestion is to add a step between 2 and 3, in order to allow a profile
to override a package's defaults, correct?
Since this scheme appears to be rather complex already, I wonder whether it
could be simplified using the additional operators you suggested. Currently
we have these:
In USE:
* `flag`: Unconditionally enable
* `-flag`: Unconditionally disable
In IUSE:
* `+flag`: Enable if unset
* `-flag`: Disable if unset
Maybe we could add the following operators to USE:
* `?+flag`: Enable if unset
* `?-flag`: Disable if unset
Sadly, we cannot use the exact same syntax in USE and IUSE, because the `-
flag` in USE already has a meaning. Hence we need the `?` variant. For
symmetry and to support intuition we could add a `+flag` syntax to USE.
Because the algorithm for applying use flags appears already very complex
currently, we could add the following operators to USE to generalise USE and
thus simplify the logic:
* `!+flag`: Enable unconditionally and lock
* `!-flag`: Disable unconditionally and lock
A "locked" use flag would mean that it cannot be further modified, unless also
using the
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Friday, 20 July 2018 08:25:05 CEST Michael Orlitzky wrote: > On 07/20/2018 02:12 AM, Mart Raudsepp wrote: > > Ok, I can see that point of view for make.conf. > > I can't agree with changes in other profiles though, as other profile > > will fall under the same category in USE_ORDER (in fact, it's the same > > thing, as the end USE from "defaults" comes from your selected profile > > and it's "parent" cascade, not taken from linux profile). But maybe you > > have it tested and know it's a problem. Have you? > > Yes, when you set USE=foo in profile A and USE="-foo" in profile A/B, > the end result is USE="foo -foo" which is the same thing as USE="-foo". > The default portage USE_ORDER makes the profile flags more important > than IUSE defaults, so the USE="-foo" from the profile clobbers any > IUSE="+foo" defaults. > > If no default was set in profile A, then no override would be necessary > in profile A/B, and the resulting USE="" would not override the IUSE > default. It appears to me that the difficulty stems from use flags being tri-state (enabled, disabled, unset), but us having only operators to enable (+) and disable (-) them in make.conf and profiles. What about adding a third operator, e.g. `^`, that resets a use flag to the unset state? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: moving default location of portage tree
On Thursday, 12 July 2018 07:21:20 CEST Ulrich Mueller wrote: > > On Wed, 11 Jul 2018, Richard Yao wrote: > > This does not answer my question. Is it really a FHS violation? The > > contents of /usr changes when doing updates using the system package > > manager. When not doing updates, it really is readonly and the FHS > > says that /usr is for readonly things. I do not see how it is > > different from anything else in /usr. > > What about a system that is building binpkgs? Or an rsync mirror? There are systems building software for other systems using $ROOT, too. They need to download into distfiles and sometimes they build binpkgs, too. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: moving default location of portage tree
On Monday, 9 July 2018 19:26:54 CEST Alec Warner wrote:
> [0] A number of people already point PORTDIR at some other location and
> appear to operate without major issues.
I do have it in /var/cache/portage/gentoo (alongside /var/cache/portage/
{distfiles,packages,local} and that works quite well.
--Dennis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] multiversion ebuilds
On Saturday, 12 May 2018 16:36:13 CEST Gerion Entrup wrote: > Am Samstag, 12. Mai 2018, 16:21:26 CEST schrieb Ulrich Mueller: > > > On Sat, 12 May 2018, Gerion Entrup wrote: > > > - The size of the tree reduces. > > > > I very much doubt that (or at least it remains to be proven). > > > > Currently, when an ebuild is copied for a version bump, it will reuse > > the same blob in the Git repository. With the scheme above, you would > > have to modify the ebuild, which would add a new blob for every > > version bump. > > You are right, I've not thought about that. However, this is only true for > the repository not for the rsync copy most(?) users have and not for a > checkout. As I understand it, rsync will indeed re-use blocks from existing files on the receiver [1], and hence copy files with the same content only once. --Dennis [1]: http://www.anchor.com.au/blog/2013/08/out-tridging-tridge/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wednesday, 9 May 2018 19:10:13 CEST Mike Gilbert wrote: > On Wed, May 9, 2018 at 12:34 PM, Matt Turner <matts...@gentoo.org> wrote: > > On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde <devuran...@gmx.net> wrote: > >> Hello! > >> > >> I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ > >> renderD128" pop up for more and more packages, probably since OpenCL > >> becomes used more widely. Hence I would like to ask: Could we in Gentoo > >> treat GPUs just like CPUs and allow any process to access render nodes > >> (i.e. the GPUs compute capabilities via the specific interface the Linux > >> kernel's DRM offers for that purpose) without sandbox restrictions? > >> > >> --Dennis > >> > >> See-Also: https://bugs.gentoo.org/654216 > > > > This seems like a bad idea. With CPUs we've had decades to work out > > how to isolate processes and prevent them from taking down the system. > > > > GPUs are not there yet. It's simple to trigger an unrecoverable GPU > > hang and not much harder to turn it into a full system lock up. > > > > This is not safe. > > It's worth noting that the default rules shipped with udev assign mode > 0666 to the /dev/dri/renderD* device nodes. So, outside of a sanbox > environment, any user may access these devices. > > This was merged as part of this PR: > https://github.com/systemd/systemd/pull/7112 Also, what's happening right now is that every ebuild that *does* somehow use DRM render nodes receives SANDBOX_PREDICT or SANDBOX_WRITE access to them. And the cycle is usually: * Bump into a usage of render nodes that breaks the build at the very end * Report a bug * Wait * The ebuild gets "allow access to the first render node" code added * Someone with 2 GPUs runs into the same issue for the second render node * ... rinse and repeat ... * Eventually, after enough people ran into it, the ebuild gets its own custom "find all render nodes and allow access" code added Additionally it appears that often the usage is indirect, through another tool or library. So for ebuild developers this is not really predictable. Thus at the very least I would suggest adding code this code (to allow access to all render nodes) to an eclass, so it is easier for ebuild developers to fix their ebuild properly, once and for all. But by then the process is so easy and already so many builds are using render nodes, that the surface for builds to take down the system is very high. If the chromium build (e.g.) could trigger a bug in Mesa that takes down the system, so could anyone else. And if we trust their toolchain (and with a build time of several hours, I believe this to be a large set of tools and a lot of code) to not bring down the system, without a complete audit or something of the sort, why don't we trust anyone else? --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wednesday, 9 May 2018 09:34:43 CEST Michał Górny wrote: > W dniu śro, 09.05.2018 o godzinie 08∶51 +0200, użytkownik Dennis > > Schridde napisał: > > I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ > > renderD128" pop up for more and more packages, probably since OpenCL > > becomes used more widely. Hence I would like to ask: Could we in Gentoo > > treat GPUs just like CPUs and allow any process to access render nodes > > (i.e. the GPUs compute capabilities via the specific interface the Linux > > kernel's DRM offers for that purpose) without sandbox restrictions? > > > > See-Also: https://bugs.gentoo.org/654216 > > Doesn't accessing those nodes involve a risk of programs being able to > crash your system (or xorg)? Or cause on-screen artifacts? Well, in the presence of Linux kernel bugs, programs could crash the whole system. But I believe this is also true for all other drivers and compute devices, including CPUs. I assume an application using render nodes could crash X by e.g. consuming all memory. But then this is also true for all applications using the CPU and its attached memory for computations. On-screen artifacts as in resolution switching and other KMS operations is explicitly prohibited. Insecure access (using GEM FLINK) to the memory of other applications (which could cause broken textures / windows with broken content) is also explicitly prohibited. So my understanding is that the answer is: No, using render nodes cannot cause on-screen artifacts (modulo the presence of Linux kernel bugs, s.a.). DRM render nodes were specifically introduced to allow GPGPU applications to run without impacting the security of the system (and without X). The Linux kernel documentation contains some information on the concept: * https://www.kernel.org/doc/html/v4.16/gpu/drm-uapi.html#render-nodes As well as an older blog post by David Herrmann: * https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/ And the Wikipedia article on DRM: * https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes --Dennis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Access to DRM render nodes from portage sandbox?
Hello! I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ renderD128" pop up for more and more packages, probably since OpenCL becomes used more widely. Hence I would like to ask: Could we in Gentoo treat GPUs just like CPUs and allow any process to access render nodes (i.e. the GPUs compute capabilities via the specific interface the Linux kernel's DRM offers for that purpose) without sandbox restrictions? --Dennis See-Also: https://bugs.gentoo.org/654216 signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH 2/3] Document default behaviour without --root-deps for EAPI 5- in ebuild(5)
--- man/ebuild.5 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/man/ebuild.5 b/man/ebuild.5 index 3c2200c..2652f89 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -344,6 +344,8 @@ For EAPIs that support \fBHDEPEND\fR (experimental \fBEAPI 5-hdepend\fR), list the \fItarget\fR dependencies, i.e. those to be installed into \fBROOT\fR. For EAPIs that do not support \fBHDEPEND\fR, the \fBemerge\fR(1) flag \fI\-\-root-deps\fR controls what the package manager installs there. +Without it, \fBemerge\fR defaults to install only runtime dependencies (i.e. +\fBRDEPEND\fR and \fBPDEPEND\fR) into \fBROOT\fR. .PP See section \fBVARIABLES\fR for more information about the \fBDEPEND\fR, \fBRDEPEND\fR and \fBHDEPEND\fR variables. -- 1.7.12
[gentoo-portage-dev] Please review: manpage-hdepend improvements
Hello! Here come a few patches to improve the HDEPEND documentation: * Minor formatting change * Description of behaviour without --root-deps * Description of targetroot useflag Best regards, Dennis
[gentoo-portage-dev] [PATCH 2/2] Document behaviour of --root-deps for EAPI 6+ in emerge(1)
--- man/emerge.1 | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/man/emerge.1 b/man/emerge.1 index ea6409c..5861bb6 100644 --- a/man/emerge.1 +++ b/man/emerge.1 @@ -711,10 +711,11 @@ of packages for \fBROOT\fR. This option is only meaningful when used together with \fBROOT\fR and it should not be enabled under normal circumstances! -For currently supported \fBEAPI\fR values, the build-time dependencies are -specified in the \fBDEPEND\fR variable. -However, behavior may change for new \fBEAPI\fRs when related extensions are -added in the future. +Affects \fBEAPI 5\fR and earlier ebuilds only. +Experimental \fBEAPI 5-hdepend\fR and later provide \fBHDEPEND\fR as a new +means to adjust installation into \fI/\fR and \fBROOT\fR. +If \fBEAPI 5\fR and earlier ebuilds are built in the same \fBemerge\fR run as +\fBEAPI 5-hdepend\fR and later ebuilds, this option affects only the former. .TP .BR \-\-select [ y | n ] Add specified packages to the world set (inverse of -- 1.7.12
[gentoo-portage-dev] [PATCH 1/2] Document HDEPEND in ebuild(5)
--- man/ebuild.5 | 46 ++ 1 file changed, 46 insertions(+) diff --git a/man/ebuild.5 b/man/ebuild.5 index 5bb1afa..a15bf55 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -316,6 +316,36 @@ the user does not specify any of the previous choices. Note that if any of the packages listed are already merged, the package manager will use that to consider the dependency satisfied. +.SS Cross-compilation +Portage supports cross-compilation into a subdirectory specified by \fBROOT\fR. +.TP +.B Host +\fIHost\fR in this context means the platform hosting the build process, i.e. +what autotools calls CBUILD. +Its packages are contained in the root of the filesystem (\fI/\fR). +If \fBROOT\fR is \fI/\fR, all dependency types will be installed there. +Otherwise, starting from experimental \fBEAPI 5-hdepend\fR, only \fBHDEPEND\fR +is installed into \fI/\fR. +In \fBEAPI 5\fR and earlier, the behaviour is controlled by the +\fI\-\-root-deps\fR flag to \fBemerge\fR(1), defaulting to install only +\fBDEPEND\fR into the \fIhost\fR. +.TP +.B Target +\fITarget\fR refers to the platform that the package will later run on, i.e. +what autotools calls CHOST. +The directory housing this system is specified by \fBROOT\fR. +If it is different from \fI/\fR, i.e. \fIhost\fR and \fItarget\fR are not the +same, this variable contains the path to the directory housing the \fItarget\fR +system. +Starting from experimental \fBEAPI 5-hdepend\fR, \fBDEPEND\fR and \fBRDEPEND\fR +list the \fItarget\fR dependencies, i.e. those to be installed into \fBROOT\fR. +In \fBEAPI 5\fR and earlier, the \fBemerge\fR(1) flag \fI\-\-root-deps\fR +controlled what the package manager installed there, defaulting to only +\fBRDEPEND\fR. +.PP +See section \fBVARIABLES\fR for more information about the \fBDEPEND\fR, +\fBRDEPEND\fR and \fBHDEPEND\fR variables. + .SH VARIABLES .TP .B Usage Notes @@ -547,6 +577,11 @@ This should contain a list of all packages that are required for the program to compile (aka \fIbuildtime\fR dependencies). These are usually libraries and headers. +Starting from experimental \fBEAPI 5-hdepend\fR, tools should go into the +\fBHDEPEND\fR variable instead, as \fBDEPEND\fR will only be installed into the +\fItarget\fR system and hence cannot be executed in a cross\-compile setting. +(See section \fBCross\-compilation\fR for more information.) + You may use the syntax described above in the \fBDependencies\fR section. .TP .B RDEPEND @@ -559,6 +594,17 @@ implicitly set. You may use the syntax described above in the \fBDependencies\fR section. .TP +.B HDEPEND +This should contain a list of all packages that are required to be executable +during compilation of this program (aka \fIhost\fR buildtime dependencies). +These are usually tools, like interpreters or (cross\-)compilers. + +This variable is new in experimental \fBEAPI 5-hdepend\fR and will be installed +into the \fIhost\fR system. +(See section \fBCross-compilation\fR for more information.) + +You may use the syntax described above in the \fBDependencies\fR section. +.TP .B PDEPEND This should contain a list of all packages that should be merged after this one (aka \fIpost\fR merge dependencies), but which may be installed by the -- 1.7.12
[gentoo-portage-dev] Please review: manpage-hdepend
Hi! These patches document HDEPEND and incorporate the suggestions Zac gave on the gentoo-portage-dev mailinglist regarding EAPI 6 vs. EAPI 5-hdepend. Best regards, Dennis
Re: [gentoo-portage-dev] Please review: manpage-hdepend
Hi! Am Montag, 24. September 2012, 14:04:10 schrieb Zac Medico: On 09/24/2012 05:16 AM, Dennis Schridde wrote: Thanks, I've applied your patches. I've also made some changes here: Tow comments: * I tried to use \fI for emphasis, cmdline flags and other minor things, and \fB for references to variables, sections, manpages, etc. (Re: \fBdo not\fR, \fBdo\fR) * Why did you drop defaulting to only \fBRDEPEND\fR from the Target subsection describing --root-deps? Was it wrong? I tried to give a quick overview over how cross-compilation is handled and what behaviour to expect. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Please review: manpage-hdepend
Am Montag, 24. September 2012, 23:18:59 schrieb Dennis Schridde: Am Montag, 24. September 2012, 14:04:10 schrieb Zac Medico: * I tried to use \fI for emphasis, cmdline flags and other minor things, and \fB for references to variables, sections, manpages, etc. (Re: \fBdo not\fR, \fBdo\fR) P.S: This seemed to be how sys-apps/man-pages and sys-apps/man-pages-posix do it. P.P.S: Thanks for applying the patches and especially for your comments and help with submitting them correctly. --Dennis signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] Please review: manpage-cleanup and -hdepend
Hi! I created 2 branches, one for manpage cleanup [1], and the other for adding hdepend documentation [2] and would like you to review and possible merge them. manpage-hdepend branches from manpage-cleanup (only 2 commits are exclusive to the former), so it is probably best to start with -cleanup and then skip over the common commits in -hdepend. Note: It is quite cumbersome to review Reorder and cleanup of ebuild(5) on the -cleanup branch as a diff. I recommend to just read the DESCRIPTION of the manpage instead. The rest should be more or less unchanged. Thanks, Dennis p.S: Please CC me, as I am not on the list. [1] https://github.com/devurandom/portage/commits/feature/manpage-cleanup [2] https://github.com/devurandom/portage/commits/feature/manpage-hdepend signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH 1/5] Adjust code of first paragraph of ebuild(5) to 80 char width
--- man/ebuild.5 | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index f4a53be..6fca6d4 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -4,12 +4,12 @@ ebuild \- the internal format, variables, and functions in an ebuild script .SH DESCRIPTION -The \fBebuild\fR(1) program accepts a single ebuild script as an argument. This script -contains variables and commands that specify how to download, unpack, -patch, compile, install and merge a particular software package from -its original sources. In addition to all of this, the ebuild script -can also contain pre/post install/remove commands, as required. All -ebuild scripts are written in bash. +The \fBebuild\fR(1) program accepts a single ebuild script as an argument. +This script contains variables and commands that specify how to download, +unpack, patch, compile, install and merge a particular software package from +its original sources. In addition to all of this, the ebuild script can also +contain pre/post install/remove commands, as required. All ebuild scripts are +written in bash. .SS Dependencies A \fIdepend atom\fR is simply a dependency that is used by portage when calculating -- 1.7.12
[gentoo-portage-dev] Please review: manpage-cleanup
Hi! I created a branch for documenting hdepend ([1] and this thread) and would like you to review and possibly merge it. This branch is based off my manpage-cleanup branch, hence I recommend reading/merging that before this one. Thanks, Dennis [1] https://github.com/devurandom/portage/commits/feature/manpage-hdepend
[gentoo-portage-dev] [PATCH 2/2] Doocument behaviour of --root-deps for EAPI 6+ in emerge(1)
--- man/emerge.1 | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/man/emerge.1 b/man/emerge.1 index ea6409c..61d86b7 100644 --- a/man/emerge.1 +++ b/man/emerge.1 @@ -711,10 +711,11 @@ of packages for \fBROOT\fR. This option is only meaningful when used together with \fBROOT\fR and it should not be enabled under normal circumstances! -For currently supported \fBEAPI\fR values, the build-time dependencies are -specified in the \fBDEPEND\fR variable. -However, behavior may change for new \fBEAPI\fRs when related extensions are -added in the future. +Affects \fBEAPI 5\fR and earlier ebuilds only. +\fBEAPI 6\fR and later provide \fBHDEPEND\fR as a new means to adjust +installation into \fI/\fR and \fBROOT\fR. +If \fBEAPI 5\fR and earlier ebuilds are built in the same \fBemerge\fR run as +\fBEAPI 6\fR and later ebuilds, this option affects only the former. .TP .BR \-\-select [ y | n ] Add specified packages to the world set (inverse of -- 1.7.12
[gentoo-portage-dev] [PATCH 2/6] Adjust code of first paragraph of ebuild(5) to 80 char width
--- man/ebuild.5 | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index f4a53be..6fca6d4 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -4,12 +4,12 @@ ebuild \- the internal format, variables, and functions in an ebuild script .SH DESCRIPTION -The \fBebuild\fR(1) program accepts a single ebuild script as an argument. This script -contains variables and commands that specify how to download, unpack, -patch, compile, install and merge a particular software package from -its original sources. In addition to all of this, the ebuild script -can also contain pre/post install/remove commands, as required. All -ebuild scripts are written in bash. +The \fBebuild\fR(1) program accepts a single ebuild script as an argument. +This script contains variables and commands that specify how to download, +unpack, patch, compile, install and merge a particular software package from +its original sources. In addition to all of this, the ebuild script can also +contain pre/post install/remove commands, as required. All ebuild scripts are +written in bash. .SS Dependencies A \fIdepend atom\fR is simply a dependency that is used by portage when calculating -- 1.7.12
[gentoo-portage-dev] [PATCH 3/6] Fix referencens to Dependencies section of ebuild(5)
--- man/ebuild.5 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 6fca6d4..f3d364e 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -544,7 +544,7 @@ override them. .TP .B DEPEND This should contain a list of all packages that are required for the -program to compile as described in \fBDEPENDENCIES\fR. +program to compile as described in \fBDependencies\fR. .TP .B RDEPEND This should contain a list of all packages that are required for this @@ -552,13 +552,13 @@ program to run (aka runtime depend). If this is not set in \fBEAPI 3\fR or earlier, then it defaults to the value of \fBDEPEND\fR. In \fBEAPI 4\fR or later, \fBRDEPEND\fR will never be implicitly set. -You may use the same syntax to vary dependencies as seen above in \fBDEPENDENCIES\fR. +You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. .TP .B PDEPEND This should contain a list of all packages that should be merged after this one, but may be merged before if need be. -You may use the same syntax to vary dependencies as seen above in \fBDEPENDENCIES\fR. +You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. .TP .B REQUIRED_USE Beginning with \fBEAPI 4\fR, the \fBREQUIRED_USE\fR variable can be -- 1.7.12
[gentoo-portage-dev] [PATCH 5/6] Improve wording of *DEPEND variable description in ebuild(5) a bit
--- man/ebuild.5 | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 3f28fce..5bb1afa 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -543,27 +543,32 @@ repo\-level USE settings, since profile and user configuration settings override them. .TP .B DEPEND -This should contain a list of all packages that are required for the -program to compile as described in \fBDependencies\fR. +This should contain a list of all packages that are required for the program +to compile (aka \fIbuildtime\fR dependencies). These are usually libraries and +headers. + +You may use the syntax described above in the \fBDependencies\fR section. .TP .B RDEPEND This should contain a list of all packages that are required for this -program to run (aka runtime depend). If this is not set in \fBEAPI 3\fR -or earlier, then it defaults to the value of \fBDEPEND\fR. In -\fBEAPI 4\fR or later, \fBRDEPEND\fR will never be implicitly set. +program to run (aka \fIruntime\fR dependencies). These are usually libraries. + +In \fBEAPI 3\fR or earlier, if this is not set, then it defaults to the value +of \fBDEPEND\fR. In \fBEAPI 4\fR or later, \fBRDEPEND\fR will never be +implicitly set. -You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. +You may use the syntax described above in the \fBDependencies\fR section. .TP .B PDEPEND This should contain a list of all packages that should be merged after this -one, but which may be installed by the package manager at any time, if that is -not possible. +one (aka \fIpost\fR merge dependencies), but which may be installed by the +package manager at any time, if that is not possible. .B ***WARNING*** .br Use this only as last resort to break cyclic dependencies! -You may use the same syntax to vary dependencies as seen above in \fBDependencies\fR. +You may use the syntax described above in the \fBDependencies\fR section. .TP .B REQUIRED_USE Beginning with \fBEAPI 4\fR, the \fBREQUIRED_USE\fR variable can be -- 1.7.12
[gentoo-portage-dev] [PATCH 6/6] Reorder description of --root-deps in emerge(1)
80 char width and max 1 sentence per line. --- man/emerge.1 | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/man/emerge.1 b/man/emerge.1 index da2c631..ea6409c 100644 --- a/man/emerge.1 +++ b/man/emerge.1 @@ -705,14 +705,16 @@ Set the \fBROOT\fR environment variable. .TP .BR \-\-root\-deps[=rdeps] If no argument is given then build\-time dependencies of packages for -\fBROOT\fR are installed to -\fBROOT\fR instead of /. If the \fBrdeps\fR argument is given then discard -all build\-time dependencies of packages for \fBROOT\fR. This option is -only meaningful when used together with \fBROOT\fR and it should not -be enabled under normal circumstances. For currently supported -\fBEAPI\fR values, the build-time dependencies are specified in the -\fBDEPEND\fR variable. However, behavior may change for new -\fBEAPI\fRs when related extensions are added in the future. +\fBROOT\fR are installed to \fBROOT\fR instead of /. +If the \fBrdeps\fR argument is given then discard all build\-time dependencies +of packages for \fBROOT\fR. +This option is only meaningful when used together with \fBROOT\fR and it should +not be enabled under normal circumstances! + +For currently supported \fBEAPI\fR values, the build-time dependencies are +specified in the \fBDEPEND\fR variable. +However, behavior may change for new \fBEAPI\fRs when related extensions are +added in the future. .TP .BR \-\-select [ y | n ] Add specified packages to the world set (inverse of -- 1.7.12
Re: [gentoo-portage-dev] Please review: manpage-cleanup
Subject should actually read: manpage-hdepend — I'm just not used to writing emails on the console using a text-editor alone… --Dennis signature.asc Description: This is a digitally signed message part.
