From: Brian Dolbec <dolsen@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT
Date: Tue, 10 May 2016 18:54:15 -0700 [thread overview]
Message-ID: <20160510185415.742432c3.dolsen@gentoo.org> (raw)
In-Reply-To: <CAJ0EP402GCmsgtKz31vYrcW09W-2Z=5B2eYPp_MYX1dwUupEpA@mail.gmail.com>
On Tue, 10 May 2016 21:42:19 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> On Tue, May 10, 2016 at 5:25 PM, Michael Orlitzky <mjo@gentoo.org>
> wrote:
> > On 05/10/2016 02:28 PM, Mike Gilbert wrote:
> >> On Tue, May 10, 2016 at 11:08 AM, Michael Orlitzky
> >> <mjo@gentoo.org> wrote:
> >>> We have maybe 150 ebuilds in the tree using $ROOT in src_*
> >>> functions. Some are bugs, but many look OK to me. Do we really
> >>> want to say "never" do that?
> >>
> >> According to PMS, it is only legal in pkg functions.
> >>
> >> Can you point to an example where using ROOT in a src function is
> >> appropriate?
> >
> > Modulo the question "when should you use $ROOT over $EPREFIX"...
> >
> > * the chrome-binary-plugins ebuilds use it in src_install.
>
> This is quite obviously wrong. I happen to maintain that ebuild, so I
> just fixed.
>
> > * dmraid does
> >
> > einfo "Appending pkg.m4 from system to aclocal.m4"
> > cat "${ROOT}"/usr/share/aclocal/pkg.m4 >>"${S}"/aclocal.m4 ||
> > \ die "Could not append pkg.m4
>
> This should be one of two things:
>
> cat /usr/share/aclocal/pkg.m4
>
> Or, if prefix support is desired:
>
> cat "${EPREFIX}"/usr/share/aclocal/pkg.m4
>
> > Both of those look like EPREFIX candidates to me, but they're not
> > obviously wrong, either. Maybe it made sense in EAPI <= 3.
> >
> > Anywhere that you need addpredict() it also seems reasonable. The
> > v4l-dvb-saa716x ebuilds use "${ROOT}/usr/src/linux/" where EPREFIX
> > would not be a good replacement.
>
> Nah, usually addpredict is dealing with stuff in the system that is
> performing the build. Sandboxed phases should never be looking at
> ROOT.
>
> Those ebuilds should probably do addpredict /usr/src/linux instead.
>
> >
> > Something needs to be fixed, though: you're right that the PMS
> > limits ROOT to pkg_*. Who knew? If we want to be serious about
> > banning ROOT in src_*, we should add a repoman error.
>
> Based on my own understanding of the ROOT variable, its use in src
> functions is always nonsensical, especially when you consider binpkgs.
> A binpkg can be installed with a ROOT value that is completely
> different from its value when the package is being compiled.
>
> To put it another way, in src functions, ROOT could/should always be
> "/". The real value of ROOT isn't determined until merge time.
>
> I agree, repoman should be catching this stuff.
>
Then Please contribute some test ebuilds for the gen-b0rk repo to test
repoman or any other Q/A apps with. If they fail to detect the test
ebuilds, it will give us something to use to help trace the code errors.
It'll also make for a much better testing system overall for any app
performing any type of Q/A on ebuilds.
--
Brian Dolbec <dolsen>
next prev parent reply other threads:[~2016-05-11 1:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-08 17:42 [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT Mike Gilbert
2016-05-10 15:08 ` Michael Orlitzky
2016-05-10 15:22 ` M. J. Everitt
2016-05-10 18:28 ` Mike Gilbert
2016-05-10 19:57 ` James Le Cuirot
2016-05-10 21:25 ` Michael Orlitzky
2016-05-10 21:27 ` Ian Stakenvicius
2016-05-11 1:42 ` Mike Gilbert
2016-05-11 1:54 ` Brian Dolbec [this message]
2016-05-11 2:40 ` Mike Gilbert
2016-05-11 2:50 ` Brian Dolbec
2016-05-11 2:19 ` Mike Gilbert
2016-05-11 2:38 ` Mike Gilbert
2016-05-14 21:35 ` Göktürk Yüksek
2016-05-16 3:09 ` Mike Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160510185415.742432c3.dolsen@gentoo.org \
--to=dolsen@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox