Re: [gentoo-dev] Things one could be upset about

[Patrick Lauer]

On Saturday 17 January 2015 13:44:21 Dirkjan Ochtman wrote:
> On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer <patrick@g.o> wrote:

> > * AutoRepoman catches issues, but no one but me seems to care
> >
> >     Fix: Remind people of
> >     http://packages.gentooexperimental.org/repoman-current-issues.txt
> >     Fix: Make it yell louder? It currently reports on IRC to
> >     #gentoo-{bugs,qa}
> I'll happily fix my repoman issues when I notice them. I try to always
> run repoman full on a package, but like you say, a tree-wide scan
> isn't really viable on a per-commit basis. Can we have AutoRepoman
> report open issues to gentoo-dev on a weekly basis? That seems like a
> fine idea to me. Per-maintainer and per-team/project/herd RSS/Atom
> feeds would also be pretty nice to have.

Most issues are transient, often fixed with either a keywording bug, or careful 
masking of useflags / pruning of old versions. Per-maintainer doesn't really 
make sense as most issues are indirect - things like "removing package.mask 
entry for new version causes dependency breakage on ia64 to become visible", 
or "dependency of dependency changed". In both cases it's often hard enough to 
figure out what caused the issue.
 
> Also, I hate something like
> "['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_pyt
> hon2_7(-)]']". What the hell kind of warning is that? I guess maybe these
> are the results of USE_EXPAND trickery and what not, but it would sure be
> nice to have something more readable.

Indeed, portage output is quite complex and often hard to read. I'm not sure 
what's the best way to improve it - I've filed a few small bugs for output 
prettyfication, but I don't even know what I'd want to be displayed for these 
useflag / blocker issues.

>
> > * Portage is too slow
> >
> >     On 'small' hardware emerge -upNDv @world can take enough time
> >     to make updates prohibitive - on an 800Mhz machine it took me
> >     about 3 days to figure out a solution to some silly blockers due to
> >     the
> >     very slow change test cycle
> >     Fix: Do some profiling and un-refactoring to remove useless code
> >     Fix: Set up a reference system (CI) to catch future regressions
>
> Why not use paludis, or another package manager?

Last time I tested paludis it was slower (and building it OOMed on that 
machine with default settings, so that's quite amusing)

Also it suffers from a hostile upstream, makes bugreports very tricky to handle 
etc.etc.

Pkgcore is in hibernation, it needs a bit more work to become really useful 
again. Possibly some ideas from pkgcore can be migrated to portage again, but 
that'd need someone with lots of free time.


Thanks for your feedback,

Patrick