public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
Date: Fri, 23 Jul 2010 13:39:00 +0100	[thread overview]
Message-ID: <20100723133900.736c2e0a@snowcone> (raw)
In-Reply-To: <4C498B6B.5040700@gentoo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Jul 2010 12:30:35 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> > In any case, abusing DEPEND isn't a mechanism for implementing use
> > requirements. You should use the mechanism that's designed for use
> > requirements to do use requirements, which means waiting for EAPI 4
> > and pkg_pretend, or just follow existing policy and pick one in the
> > case of a conflict.
> 
> Abusing depend is a good way to do this, until we get better tools.

No, it's not, because it doesn't work. Assuming self deps are legal in
the || ( myself myself-bin ) case, they can't do what you want for use
requirements. myself[foo] would be met when building with USE=-foo so
long as myself[foo] was installed originally, and it wouldn't be met
unless myself were already installed.

> I have to agree with Brian's proposal and say that in this particular
> case, the best solution is required_use and not pkg_pretend.

required_use may theoretically allow a package manager to do cycle
breaking if all the relevant packages are updated to export information
about which flags are and are not safe to toggle, but since no-one's
proposed exporting that information or has even worked out exactly what
the requirements would be for that to happen, and since pkg_pretend is
required anyway for other things, just going with pkg_pretend for now
is the sensible solution.

Of course, this is all irrelevant since at the current rate of progress
Portage is two years off any of this being available for developers
anyway...

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkxJjWoACgkQ96zL6DUtXhEpzQCfWxZS/6t+U+5n/ASlR4cUbC07
ofkAoMTbjrwE3d19xaapxcB58eEJn3qX
=F3XH
-----END PGP SIGNATURE-----

  reply	other threads:[~2010-07-23 12:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-22 16:20 [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog Thomas Beierlein
2010-07-22 18:04 ` Jorge Manuel B. S. Vicetto
2010-07-23  7:06   ` Thomas Beierlein
2010-07-23  8:38     ` Tomáš Chvátal
2010-07-23 12:10       ` Thomas Beierlein
2010-07-23  9:31     ` Tiziano Müller
2010-07-23 11:30       ` Thomas Beierlein
2010-07-23 11:37         ` Ciaran McCreesh
2010-07-23 12:30           ` Jorge Manuel B. S. Vicetto
2010-07-23 12:39             ` Ciaran McCreesh [this message]
2010-07-23 12:28       ` Jorge Manuel B. S. Vicetto
2010-07-23 12:43         ` Ciaran McCreesh

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=20100723133900.736c2e0a@snowcone \
    --to=ciaran.mccreesh@googlemail.com \
    --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