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. 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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
