| 1 |
Zac Medico posted on Mon, 04 Oct 2010 10:40:29 -0700 as excerpted: |
| 2 |
|
| 3 |
> On 10/04/2010 12:50 AM, Michael Haubenwallner wrote: |
| 4 |
>> |
| 5 |
>> On 09/30/2010 09:36 AM, Andreas K. Huettel wrote: |
| 6 |
>>> [Portage is something] that I really need to rely on, |
| 7 |
>>> so whatever I do, I'll keep [it] stable. |
| 8 |
>>> |
| 9 |
>>> (My development machine(s) are also my real-life work machines.) |
| 10 |
|
| 11 |
>> So - would it make sense to split repoman into its own ebuild? |
| 12 |
|
| 13 |
> The thing is, parts of repoman are closely coupled to portage internals. |
| 14 |
> So, if we split it out then in practice we'd end up having to do repoman |
| 15 |
> version bumps to correspond with portage version bumps, which would |
| 16 |
> eliminate any practical gain that we'd get from distributing it with a |
| 17 |
> separate ebuild. |
| 18 |
|
| 19 |
Accepting what you wrote at face value, we've established that there must |
| 20 |
be a repoman version for each portage version (or rather, portage series). |
| 21 |
|
| 22 |
But does the inverse also hold, that for each repoman version there must |
| 23 |
be a portage version? IOW, is there a 1:1 correspondence or can it be |
| 24 |
1:x, where x varies? |
| 25 |
|
| 26 |
So in the context of this thread, it would then be possible to release a |
| 27 |
repoman with the new feature/warning, one-each for each current portage |
| 28 |
series (three, now, stable, ~arch and masked-2.2, four if HEAD is also |
| 29 |
counted). Of course this wouldn't work for repoman features that are very |
| 30 |
closely tied to new portage features, not yet in stable portage, but it |
| 31 |
could work for others. Each current portage series would then have at |
| 32 |
least one repoman version, but where needed, they could "tick" separately, |
| 33 |
simply kept series-synced with a new repoman version for each portage |
| 34 |
series when necessary. |
| 35 |
|
| 36 |
But it could also well be that while such is possible, it'd be so much |
| 37 |
more work that it's not practical, as it would ultimately drive our ever- |
| 38 |
patient portage devs to burn-out. =:^( I don't know. I'm simply asking. |
| 39 |
|
| 40 |
-- |
| 41 |
Duncan - List replies preferred. No HTML msgs. |
| 42 |
"Every nonfree program has a lord, a master -- |
| 43 |
and if you use the program, he is your master." Richard Stallman |
Archives