Re: [gentoo-portage-dev] plugin-sync progress report

[Brian Dolbec]

On Sat, 15 Mar 2014 21:48:59 +0100
Sebastian Luther <SebastianLuther@×××.de> wrote:

> Am 15.03.2014 21:32, schrieb Brian Dolbec:
> > I've started working on the repository/config.py changes needed for
> > the plugin-sync system.
> >
> > First:
> >   The following class performed checks on the
> > repos.conf entries for the sync variables regardless if they were
> > being used or not. [...]
> >
> > Second:
> >   - Should all the repos.conf entires to be synced be validated
> > prior to syncing and fail if there are any errors?
> >   - Or, just call each sync module's sync() and let each fail
> > individually and continue syncing remaining repos?
> >
>
> Maybe that's just me, but I don't like things that sometimes work and
> sometimes not. Having some emerge invocations fail with "broken
> config" and some not, seems rather ugly to me.
>
> (This also implies that syncing a repo with working config is not
> possible as long as there are repos with broken config.)
>

So, what your saying is EVERY time emerge is run or portage is imported
for api use.  It _MUST_ load the sync modules and  verify the sync
parameters regardless if those setting will be used or NOT.  That is a
waste of resources and time to me.  Portage is already far too slow.  I
admit, that this will not be much of a time/resource consumer for the
majority of gentoo systems.  But what about low power systems, where
resources including memory are at a premium?  After all, how many times
do you edit your repos.conf files?  Why test them for every possible
error every time portage code is started up?

I was intending on adding a check-config option to the emaint sync
module I planned on adding.  I think that is a good compromise between
over checking and no checking at all.


> > Third:
> >   - I would like to add a new config item for all repos.
> >     It is a variable to define which sources of sync operations
> > which the repo will be allowed to be synced from.  It could be a
> > space separated list which could be used to prevent it from being
> > synced via certain commands.
>
> What exactly does this variable mean? What are emaint or layman doing
> here?
>
>
>

emaint is here because I intend on making an emaint sync module for
doing more detailed sync operations.  Like syncing individual repos. If
a user had an overlay that they did not want to be synced via emerge
then not putting emerge there, when the emerge --sync command was
started. It would skip syncing that repo, even though it had a
sync-type and sync-url.  Layman was an entry there since most overlays
are installed & managed by it.  So, would have been a possible entry.
 

Alex's solution seems like a good fit in place of this.  See his email
reply.


-- 
Brian Dolbec <dolsen>