Re: [gentoo-dev] Re: Reminder: please use the latest Portage/repoman version to commit to tree

[Zac Medico]

On 10/04/2010 09:13 PM, Duncan wrote:
> Zac Medico posted on Mon, 04 Oct 2010 10:40:29 -0700 as excerpted:
>
>> On 10/04/2010 12:50 AM, Michael Haubenwallner wrote:
>>>
>>> On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
>>>> [Portage is something] that I really need to rely on,
>>>> so whatever I do, I'll keep [it] stable.
>>>>
>>>> (My development machine(s) are also my real-life work machines.)
>
>>> So - would it make sense to split repoman into its own ebuild?
>
>> The thing is, parts of repoman are closely coupled to portage internals.
>> So, if we split it out then in practice we'd end up having to do repoman
>> version bumps to correspond with portage version bumps, which would
>> eliminate any practical gain that we'd get from distributing it with a
>> separate ebuild.
>
> Accepting what you wrote at face value, we've established that there must
> be a repoman version for each portage version (or rather, portage series).
>
> But does the inverse also hold, that for each repoman version there must
> be a portage version?  IOW, is there a 1:1 correspondence or can it be
> 1:x, where x varies?
>
> So in the context of this thread, it would then be possible to release a
> repoman with the new feature/warning, one-each for each current portage
> series (three, now, stable, ~arch and masked-2.2, four if HEAD is also
> counted).  Of course this wouldn't work for repoman features that are very
> closely tied to new portage features, not yet in stable portage, but it
> could work for others.  Each current portage series would then have at
> least one repoman version, but where needed, they could "tick" separately,
> simply kept series-synced with a new repoman version for each portage
> series when necessary.

Yeah, I supposed that would work. However, I don't see new repoman
checks being being added quickly enough to make it worth the effort. If
people just have a little patience then the portage with the latest
repoman checks will be stabilized soon enough.

> But it could also well be that while such is possible, it'd be so much
> more work that it's not practical, as it would ultimately drive our ever-
> patient portage devs to burn-out.  =:^(  I don't know.  I'm simply asking.

Well, I just don't see a good benefit/cost ratio here. I don't think
people will be getting shiny new repoman features fast enough to make it
worth the extra effort.
-- 
Thanks,
Zac