| 1 |
On 10/20/2013 07:41 PM, Markos Chandras wrote: |
| 2 |
> On 10/20/2013 11:40 AM, Patrick Lauer wrote: |
| 3 |
> |
| 4 |
>>> The affected packages can slowly be fixed. It's not like they are |
| 5 |
>>> totally broken but it's more like of another way to tell you that |
| 6 |
>>> a few QA problems exist and that it would be nice to fix them |
| 7 |
>>> whenever you find some time. |
| 8 |
> |
| 9 |
>> You mean situations where there is user-visible breakage in the |
| 10 |
>> dependency graphs? |
| 11 |
> |
| 12 |
>> If I were a member of the QA team (which for various reasons I've |
| 13 |
>> never been allowed to be, which is quite hilarious) I'd ask you to |
| 14 |
>> remember the "repoman || die" motto we beat into every new recruit |
| 15 |
>> and/or ask you to honourably disable your commit privileges. |
| 16 |
> |
| 17 |
> |
| 18 |
> No I never meant broken depgraphs. Well for broken deps, repoman does |
| 19 |
> not let you commit. If you use --force to workaround broken deps, |
| 20 |
> well, then you get what you deserve. |
| 21 |
|
| 22 |
Sadly that's not true - for ebuild additions and most keyword changes |
| 23 |
repoman works well. But you can make things fail in many creative ways, |
| 24 |
like ... |
| 25 |
|
| 26 |
- stale or only partially up-to-date checkout |
| 27 |
- package.mask changes |
| 28 |
- accidental stable keyword removal |
| 29 |
- accidental slot or useflag removal |
| 30 |
- failed commits (easy to accidentally overlook) |
| 31 |
|
| 32 |
and so on. Most of that affects reverse dependencies, which are not |
| 33 |
checked by default - a good part of the depgraph breakage could be |
| 34 |
avoided if everyone ran full-tree scans, but that's extremely |
| 35 |
time-consuming (I'm burning 120 CPU-minutes @ 3.4Ghz amd64 for a full |
| 36 |
tree scan) and inconvenient. |
| 37 |
|
| 38 |
So for now I just hope that my constant bug-nagging motivates people to |
| 39 |
be a bit more careful :) |
Archives