public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian Dolbec <dolsen@gentoo.org>
To: Alec Warner <antarus@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Deprecating repoman
Date: Fri, 11 Mar 2022 11:04:14 -0800	[thread overview]
Message-ID: <20220311110414.03602178@storm> (raw)
In-Reply-To: <CAAr7Pr8CCqD-U4kohssb9U4h_gpnQNsXpxdxx34cphW-XiAAPw@mail.gmail.com>

On Fri, 11 Mar 2022 10:25:19 -0800
Alec Warner <antarus@gentoo.org> wrote:

> On Fri, Mar 11, 2022 at 9:14 AM Peter Stuge <peter@stuge.se> wrote:
> >
> > Matt Turner wrote:  
> > > repoman is inferior to other tooling mentioned. The other tooling
> > > is actually run in CI.  
> >
> > The problem seems to be that CI is running something other than
> > developers run, not the other way around.
> >
> >  
> > > Developers should get the same warnings locally as in CI.  
> >
> > I agree. And developers and their tools should not have to bend to
> > whatever CI does, I think the other way around makes more sense.
> >
> >
> > CI doesn't use repoman because of performance issues.  
> 
> I think the problem is that making committers use the CI tool is
> technically a fairly straightforward change; while everything you
> discuss further in the thread is not; because it implies people will
> work on improving tools that have shown little or no progress on
> improving in the 15 years I've been in Gentoo.
> 

Somewhat incorrect here.  I did the majority of the re-write to make
the code maintainable, extensible not that long ago.  It even has the
ability to be repository configurable and include the ability for
custom repository plugin checks to be added and run.   The CI system was
being developed at the same time using pkgcheck.

See my other reply to WilliamH for more detail about that and
fundamental speed differences.



> >
> > What if pkgcore evolves to provide a portage-compatible API?  
> 
> No API is planned and no one is working on it.
> 

I and a few others did some work to ensure pkgcore had some usable
api's from early in it's development.  But pkgcore is so different from
portage code, it was difficult for early to mediocre python devs to
wrap their head around.   There was even work to make porthole be able
to use pkgcore as it's backend package manager, but it was never fully
utilized due to more work needed on pkgcore for some functionality.


> >
> > Then CI could use repoman without performance problems, and
> > developers would also enjoy improved performance, without spending
> > time on replacing tooling which already works for them.  
> 

No, pkgcore and it's QA tool pkgcheck are designed to work together.
Repoman is designed to work with portage base code.   Checks can be
designed to work on either, but not both.   The missing checks that
the CI does can be added to repoman, but the primary dev(s) creating
them on the CI don't recreate them for repoman.  They want to work on
pkgcheck.

Repoman code will NEVER be as fast as pkgcheck due to the legacy
portage code structure it relies on.   Pkgcore was a re-design from the
ground up to to improve upon the shortcomings of the original portage
structure. This resulted in vast speed improvements and reduction in
lines of code to do the same functionality.   Portage (due to Zac) has
made vast improvements in structure, but still requires a ton more
changes to get to where it should be.


> The benefit of getting people to change their behavior is that the
> benefits (less breakage, better tooling) are achieved now; as opposed
> to in some hypothetical future where repoman is improved.
> Note that we have been waiting for 'improved repoman' for about 8
> years; so..I'm not willing to bet on it when we have better tooling
> that works today and the primary complaint is that...what exactly?
> 
> The new workflow with pkgcheck was announced at the end of 2019:
> https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck
> 
> It's been 2 years, I think we can bring everyone into the fold here.
> 
> >
> > Looking into the future then maybe portage could even come to use
> > pkgcore for the low-level things that pkgcore does, then even users
> > could enjoy improved performance.  
> 
> Many things could happen but again, if you talk to people who work on
> pkgcore; there is no concrete plan for this. So I don't see why we are
> betting on it happening.
> 
> If you read radhermit's blog:
> https://pkgcraft.github.io/posts/timesink-chronicles/ you can get one
> take on the project and why it struggled.
> 
> -A
> 
> >
> >
> > Right?
> >
> > //Peter
> >  
> 



  reply	other threads:[~2022-03-11 19:04 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 21:00 [gentoo-dev] Deprecating repoman Matt Turner
2022-03-09 21:14 ` Rich Freeman
2022-03-09 21:19   ` Matt Turner
2022-03-09 21:37     ` Matthias Maier
2022-03-09 21:47       ` Matt Turner
2022-03-09 22:33         ` Matthias Maier
2022-03-09 23:32           ` Matt Turner
2022-03-10  0:17             ` Matthias Maier
2022-03-10  0:51               ` Matt Turner
2022-03-10 18:28         ` Joshua Kinard
2022-03-10 19:44           ` Andreas K. Huettel
2022-03-10 21:53             ` Joshua Kinard
2022-03-10 22:00               ` John Helmert III
2022-03-10 19:59           ` Alec Warner
2022-03-10 21:57             ` Joshua Kinard
2022-03-10 22:04               ` Sam James
2022-03-09 21:23 ` Brian Evans
2022-03-09 21:25 ` Ionen Wolkens
2022-03-19  4:43   ` Zoltan Puskas
2022-03-19  7:15     ` Ulrich Mueller
2022-03-19  8:48       ` Michał Górny
2022-03-09 21:25 ` Anna Vyalkova
2022-03-09 21:27 ` Maciej Barć
2022-03-09 21:28   ` Matt Turner
2022-03-09 21:32     ` Brian Evans
2022-03-09 21:45       ` Matt Turner
2022-03-10  7:09 ` Joonas Niilola
2022-03-10 17:29   ` Matt Turner
2022-03-10 18:07     ` William Hubbs
2022-03-10 18:22       ` John Helmert III
2022-03-11  7:30       ` Anna Vyalkova
2022-03-11 16:49       ` Brian Dolbec
2022-03-11 17:14     ` Peter Stuge
2022-03-11 18:25       ` Alec Warner
2022-03-11 19:04         ` Brian Dolbec [this message]
2022-03-11 19:51         ` Joshua Kinard
2022-03-11 20:11           ` Arthur Zamarin
2022-03-12  1:45           ` Sam James
2022-03-12  1:54       ` Sam James
2022-03-10 18:27 ` Joshua Kinard
2022-03-10 19:58   ` Alec Warner
2022-03-10 23:18     ` Joshua Kinard
2022-03-11  8:54       ` Mart Raudsepp
2022-03-11 19:39         ` Joshua Kinard
2022-03-12  1:54           ` Sam James
2022-03-12  2:17             ` Joshua Kinard
2022-03-12  1:57       ` Sam James
2022-03-12  2:53         ` Joshua Kinard
2022-03-12 10:37           ` Mart Raudsepp
2022-03-11 19:38     ` Ulrich Mueller
2022-03-11 21:19 ` [gentoo-dev] " Matt Turner
2022-03-12  8:33   ` Fabian Groffen
2022-03-12 19:21     ` [gentoo-dev] " Hank Leininger
2022-03-12 20:26   ` [gentoo-dev] " Matt Turner
2022-03-13 22:52     ` Matt Turner
2022-03-12  0:43 ` [gentoo-dev] " Francesco Riosa
2022-03-12  0:46   ` Matt Turner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220311110414.03602178@storm \
    --to=dolsen@gentoo.org \
    --cc=antarus@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox