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