public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tom Wijsman <TomWij@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Cc: gentoo-dev@lists.gentoo.org
Subject: [gentoo-portage-dev] [IDEA] Enumerate solutions for blockers, to avoid tedious manual work. (was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Date: Sun, 3 Nov 2013 13:10:57 +0100	[thread overview]
Message-ID: <20131103131057.4e71d3ec@TOMWIJ-GENTOO> (raw)
In-Reply-To: <52760EF9.4030908@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]

On Sun, 03 Nov 2013 10:53:13 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 02/11/2013 17:03, Michał Górny wrote:
> Sadly, it's somewhat common for (newish) users to not know what to do
> with that. Blocker output can be quite daunting in the beginning,
> especially if it's in the middle of 20 other things portage is also
> updating.

+1 I agree, we should look into having errors not only tell what we
should not do, but also tell what we could do; every time I see a
blocker it is annoying that I have to go manually search the solution.

Let's say I have the blocker:

    <dev-python/python-exec-10000 is blocking
    dev-lang/python-exec-0.3.1

We could have it additionally say something like:

    To resolve this blocker, you can run one of the following commands:

        emerge -1 '>=dev-python/python-exec-10000'
        
Taking another example:

    <dev-lang/vala-0.20.0" is blocking
    dev-libs/gobject-introspection-1.36.0-r1

Why not have it say:

    To resolve this blocker, you can run one of the following commands:

        emerge -1 '>=dev-lang/vala-0.20.0'
        emerge -1 '<dev-libs/gobject-introspection-1.36.0'

For the last example it was smart enough to see 1.36.0 and 1.36.0-r1
have this blocker, whereas the lower versions did not; and if there's a
range, it could just list all options.

This spares me out from having to inspect "${PORTDIR}"/dev-lang/vala
and "${PORTDIR}"/dev-libs/gobject-introspection manually to figure out
what's really going on; it's quite repetitive work that we currently
need to do manually for every blocker we meet, which can be automated.

Do other people like this idea? Should it be worded differently? If so,
I might try to work out a patch together with the Portage team.

!! Moving this sub discussion to the Portage Dev ML; please respond
there and drop gentoo-dev from CC, thank you very much in advance.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

           reply	other threads:[~2013-11-03 12:11 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <52760EF9.4030908@gmail.com>]

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=20131103131057.4e71d3ec@TOMWIJ-GENTOO \
    --to=tomwij@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=gentoo-portage-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