public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [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)
       [not found]     ` <52760EF9.4030908@gmail.com>
@ 2013-11-03 12:10       ` Tom Wijsman
  0 siblings, 0 replies; only message in thread
From: Tom Wijsman @ 2013-11-03 12:10 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2013-11-03 12:11 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <5274FB3D.8080508@gentoo.org>
     [not found] ` <20131102145126.3c1f6cd7@TOMWIJ-GENTOO>
     [not found]   ` <20131102160330.0e6eaa5e@gentoo.org>
     [not found]     ` <52760EF9.4030908@gmail.com>
2013-11-03 12:10       ` [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) Tom Wijsman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox