| 1 |
On Fri, 11 Mar 2022 10:25:19 -0800 |
| 2 |
Alec Warner <antarus@g.o> wrote: |
| 3 |
|
| 4 |
> On Fri, Mar 11, 2022 at 9:14 AM Peter Stuge <peter@×××××.se> wrote: |
| 5 |
> > |
| 6 |
> > Matt Turner wrote: |
| 7 |
> > > repoman is inferior to other tooling mentioned. The other tooling |
| 8 |
> > > is actually run in CI. |
| 9 |
> > |
| 10 |
> > The problem seems to be that CI is running something other than |
| 11 |
> > developers run, not the other way around. |
| 12 |
> > |
| 13 |
> > |
| 14 |
> > > Developers should get the same warnings locally as in CI. |
| 15 |
> > |
| 16 |
> > I agree. And developers and their tools should not have to bend to |
| 17 |
> > whatever CI does, I think the other way around makes more sense. |
| 18 |
> > |
| 19 |
> > |
| 20 |
> > CI doesn't use repoman because of performance issues. |
| 21 |
> |
| 22 |
> I think the problem is that making committers use the CI tool is |
| 23 |
> technically a fairly straightforward change; while everything you |
| 24 |
> discuss further in the thread is not; because it implies people will |
| 25 |
> work on improving tools that have shown little or no progress on |
| 26 |
> improving in the 15 years I've been in Gentoo. |
| 27 |
> |
| 28 |
|
| 29 |
Somewhat incorrect here. I did the majority of the re-write to make |
| 30 |
the code maintainable, extensible not that long ago. It even has the |
| 31 |
ability to be repository configurable and include the ability for |
| 32 |
custom repository plugin checks to be added and run. The CI system was |
| 33 |
being developed at the same time using pkgcheck. |
| 34 |
|
| 35 |
See my other reply to WilliamH for more detail about that and |
| 36 |
fundamental speed differences. |
| 37 |
|
| 38 |
|
| 39 |
|
| 40 |
> > |
| 41 |
> > What if pkgcore evolves to provide a portage-compatible API? |
| 42 |
> |
| 43 |
> No API is planned and no one is working on it. |
| 44 |
> |
| 45 |
|
| 46 |
I and a few others did some work to ensure pkgcore had some usable |
| 47 |
api's from early in it's development. But pkgcore is so different from |
| 48 |
portage code, it was difficult for early to mediocre python devs to |
| 49 |
wrap their head around. There was even work to make porthole be able |
| 50 |
to use pkgcore as it's backend package manager, but it was never fully |
| 51 |
utilized due to more work needed on pkgcore for some functionality. |
| 52 |
|
| 53 |
|
| 54 |
> > |
| 55 |
> > Then CI could use repoman without performance problems, and |
| 56 |
> > developers would also enjoy improved performance, without spending |
| 57 |
> > time on replacing tooling which already works for them. |
| 58 |
> |
| 59 |
|
| 60 |
No, pkgcore and it's QA tool pkgcheck are designed to work together. |
| 61 |
Repoman is designed to work with portage base code. Checks can be |
| 62 |
designed to work on either, but not both. The missing checks that |
| 63 |
the CI does can be added to repoman, but the primary dev(s) creating |
| 64 |
them on the CI don't recreate them for repoman. They want to work on |
| 65 |
pkgcheck. |
| 66 |
|
| 67 |
Repoman code will NEVER be as fast as pkgcheck due to the legacy |
| 68 |
portage code structure it relies on. Pkgcore was a re-design from the |
| 69 |
ground up to to improve upon the shortcomings of the original portage |
| 70 |
structure. This resulted in vast speed improvements and reduction in |
| 71 |
lines of code to do the same functionality. Portage (due to Zac) has |
| 72 |
made vast improvements in structure, but still requires a ton more |
| 73 |
changes to get to where it should be. |
| 74 |
|
| 75 |
|
| 76 |
> The benefit of getting people to change their behavior is that the |
| 77 |
> benefits (less breakage, better tooling) are achieved now; as opposed |
| 78 |
> to in some hypothetical future where repoman is improved. |
| 79 |
> Note that we have been waiting for 'improved repoman' for about 8 |
| 80 |
> years; so..I'm not willing to bet on it when we have better tooling |
| 81 |
> that works today and the primary complaint is that...what exactly? |
| 82 |
> |
| 83 |
> The new workflow with pkgcheck was announced at the end of 2019: |
| 84 |
> https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck |
| 85 |
> |
| 86 |
> It's been 2 years, I think we can bring everyone into the fold here. |
| 87 |
> |
| 88 |
> > |
| 89 |
> > Looking into the future then maybe portage could even come to use |
| 90 |
> > pkgcore for the low-level things that pkgcore does, then even users |
| 91 |
> > could enjoy improved performance. |
| 92 |
> |
| 93 |
> Many things could happen but again, if you talk to people who work on |
| 94 |
> pkgcore; there is no concrete plan for this. So I don't see why we are |
| 95 |
> betting on it happening. |
| 96 |
> |
| 97 |
> If you read radhermit's blog: |
| 98 |
> https://pkgcraft.github.io/posts/timesink-chronicles/ you can get one |
| 99 |
> take on the project and why it struggled. |
| 100 |
> |
| 101 |
> -A |
| 102 |
> |
| 103 |
> > |
| 104 |
> > |
| 105 |
> > Right? |
| 106 |
> > |
| 107 |
> > //Peter |
| 108 |
> > |
| 109 |
> |
Archives