Re: [gentoo-dev] minimalistic emerge

[Igor]

Hello Kent,

Friday, August 8, 2014, 9:29:54 PM, you wrote:

But it's possible to fix many problems even now!

What would you tell if something VERY simple is implemented like - reporting 
every emerge failed due to slot conflict back home with details for inspection?

If maintainers had that kind of data then they could learn from the wild. I don't know what 
they would learn but I know it would be a very useful experience that might jump start 
evolution - useful updates to emerge and other tools. Almost every system designed by nature has 
feedback functions. It's the safe update - it will work even if not optimal from the start
or even if it's not clear what it will help to learn. The quality of ebuilds would improve too.

And from the useful life database new tools could evolve like - bug reporting automatization a 
whole new world of tool.

http://db.gentoo.org/report/

     System: System name 
       Arch: 
Package emerged: ....
Environment: ....
Dependency graph: .... -> ... -> ...
Fail message:

* 3 reports per day are accepted from one single IP
* no dups 

http://db.gentoo.org/stats/

- SlickGrid stats

Arch Package How many times Failed Fail message 

Click on Package -> Dependency Graph 

If GENTOO had everything emerging from any state (goal unattainable but desirable) that 
would be a great advantage for the users. That feel of a lean mean machine that saves time - it's 
tasty - new fans warranted.



On 9 August 2014 04:58, Igor <lanthruster@×××××.com> wrote:
Maintainers have no feedback from their ebuilds, they all do their best but there are no tools 
to formalize their work. No compass. They have no access to user 
space where the packages are installed, unaware how users are using their ebuilds. It's the design 
failure that hunts Gentoo from the start - no global intellectual bug tracking system. Doing not mistakes
- not possible, the automated tracking sub-systems should be there but... we are where we are. 
Some of that is doable, ie: we could have installation metrics systems like CPAN has a testers network with a matrix showing where a given thing is failing : http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126

But its a lot of work investment to support.

And beyond "it installs" and "its tests pass", its piratically infeasible to track software failing beyond there.

And some of the reasons we have dependency declarations are to avoid problems that will ONLY be seen at runtime and WONT be seen during installation or testing. ( Usually because the problem was found before there were tests for it )

For that, only manual feedback systems, such as our present bugzilla, are adequate. 


-- 
Kent 

KENTNL - https://metacpan.org/author/KENTNL





-- 
Best regards,
 Igor                            mailto:lanthruster@×××××.com