public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Date: Fri, 20 Dec 2019 09:25:44 -0500	[thread overview]
Message-ID: <CAGfcS_nq4h7ZMaOwARqNf7L=bu6-e61oRC0kfFbpY2=MbYbTaQ@mail.gmail.com> (raw)
In-Reply-To: <4696869.rFTB5HQvXR@falbala>

On Fri, Dec 20, 2019 at 8:41 AM Gerion Entrup <gerion.entrup@flump.de> wrote:
>
> Am Donnerstag, 19. Dezember 2019, 19:43:37 CET schrieb Sebastian Pipping:
> > On 19.12.19 18:37, Michał Górny wrote:
> > > We have a better alternative that lets us limit the impact on the users.
> > > Why not use it?
> >
> > Which one?  The CMake bootstrap copy?  The adding to stage3 one?
>
> If an error message can be shown, maybe this is enough as a hint:
> "expat and cmake have circular dependencies. Emerge it the first time with:
> USE=bundled-cmake emerge -1 cmake expat
> and then just don't care anymore about this use flag."
>

Not sure about custom error messages but in any case when using that
bundled-cmake USE flag it would probably make sense to do an ewarn
that the bundling took place and is only intended for temporary use,
and that the package should be re-merged without the flag once expat
is working.  That would also cover users who inadvertently set the
flag.

I think that bundled-cmake also might make more sense than
system-cmake, even though the latter is more established.  We have a
lot of users who set USE=-* and that means they're going to end up
with lots of stuff bundled that doesn't need to be.  I'm no fan of
USE=-* in general but it seems like we should try to avoid making not
setting a USE flag the less secure option since it does happen a lot.

I'm just commenting on the USE-based solution.  The compat package
solution obviously bypasses this particular problem entirely.

-- 
Rich


  reply	other threads:[~2019-12-20 14:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1a722f8f-36b5-c313-b6e1-eac75e0839c5@gentoo.org>
2019-12-18 21:02 ` [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake Sebastian Pipping
2019-12-18 21:08   ` Michał Górny
2019-12-18 21:10     ` Piotr Karbowski
2019-12-18 21:14       ` Michał Górny
2019-12-18 21:44   ` Francesco Riosa
2019-12-19 13:32     ` Rolf Eike Beer
2019-12-19 14:18       ` Sebastian Pipping
2019-12-18 23:58   ` Sergei Trofimovich
2019-12-19  1:38     ` Kent Fredric
2019-12-19  8:31     ` Michał Górny
2019-12-19 14:39       ` Sebastian Pipping
2019-12-19 16:03         ` Michał Górny
2019-12-19 17:28           ` Sebastian Pipping
2019-12-19 17:37             ` Michał Górny
2019-12-19 18:43               ` Sebastian Pipping
2019-12-19 19:21                 ` Michał Górny
2019-12-20 13:41                 ` Gerion Entrup
2019-12-20 14:25                   ` Rich Freeman [this message]
2019-12-19 21:28               ` Michael Orlitzky
2019-12-19  0:19   ` Michael Orlitzky

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='CAGfcS_nq4h7ZMaOwARqNf7L=bu6-e61oRC0kfFbpY2=MbYbTaQ@mail.gmail.com' \
    --to=rich0@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