Re: [gentoo-portage-dev] a feature called stabilize wanted
On Wednesday 10 March 2010 10:58:45 Johannes Kellner wrote: Hello List ans anyone! I'm searching for a feature or an hint how and where to implement it. The desired feature could be called stabilize or update to stable and would change the selected packages when doing an update (emerge -avuND world). [snip] Anyone, could help me? Give me a hint if this would be possible? Any hints where in code this could be implemented? I'm programmer, professional, so if I get the right hints, will invest spare time in this. Also I'll ready to setup and run various tests. But I never before worked at portage... It might be a good start if the people with the Know-How, will start a discussing about this idea, what problems need to be solved, which code parts will need an update and so one. Than I could try to get it working, but right now, I doesn't even know the right questions. Best regards, - Johannes Kellner At first glance your idea seems very interesting. However the versions you end up with under your system critically depends on the timing between when things go stable and when you perform an update. You could skip past a ~ version that is just about to go stable, because a newer ~ was visible, but if you'd waited just a bit longer with syncing and updating you would have gotten the stable version and no further update would have gotten you the newer ~ version. If you still wish to implement it anyway, then I would suggest that you need a new keyword modifier to indicate ``highest stable version or if that is not available the highest testing version'' and adapt the visibility code to understand that new keyword modifier and make the appropriate versions visible. I don't actually know about portage internals, but this is how I imagine it should work. Marijn
[gentoo-portage-dev] a feature called stabilize wanted
Hello List ans anyone! I'm searching for a feature or an hint how and where to implement it. The desired feature could be called stabilize or update to stable and would change the selected packages when doing an update (emerge -avuND world). Just to give you an initial idea/example, some packages: package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 So version numbers with the ~ are unstable/~amd64, where numbers without are stable/amd64. Case 1 (amd64): using system wide only stable/amd64 Installing anything would result in a...@3.8 and C,B not installed Case 2 (~amd64): using system wide the unstable/~amd64 keyword Installing anything would result in a...@~3.9 b...@~1.6 c...@~1.1 Case 3 (real world): get it managed with masks and keywords that the major packages are stable, while new features could arrive Installing anything with the result a...@3.8 b...@~1.6 c...@~1.1 Nothing new so far, now new package versions arrive: package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 NEW: 4.0 ~4.1 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 NEW: 1.8 ~1.9 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 NEW: ~1.2 ~1.4 So if we now update (emerge -avuND) right now the results are: Case 1 (amd64): Update a...@3.8 to 4.0, B,C not installed Case 2 (~amd64): Update a...@~3.9 to ~4.1, b...@~1.6 to ~1.9, c...@~1.1 to ~1.4 Case 3 (real world): depends on the new set of masks and keywords... much work ahead What I search is the stabilize feature for the update e.g. (emerge -avusND) should result in: Case 1 (amd64): - update a...@3.8 to a...@4.0, because a new stable version updates the old stable version - B, C not installed Case 2 (~amd64): - update a...@~3.9 to a...@4.0 update unstable packages to the stable version when arrived, stop using unstable. - update b...@~1.6 to b...@1.8 update unstable packages to the stable version when arrived, stop using unstable. - update c...@~1.1 to C~1.4 update unstable packages, the never unstable versions. Case 3 (real world): - update a...@3.8 to a...@4.0 update stable package to newer stable version when arrived. - update b...@~1.6 to b...@1.8 update unstable packages to the stable version when arrived, stop using unstable. - update c...@~1.1 to C~1.4 update unstable packages, the never unstable versions. Optional: make is possible to ignore/filter/select the unstable to unstable updates, those might cause trouble. Anyone, could help me? Give me a hint if this would be possible? Any hints where in code this could be implemented? I'm programmer, professional, so if I get the right hints, will invest spare time in this. Also I'll ready to setup and run various tests. But I never before worked at portage... It might be a good start if the people with the Know-How, will start a discussing about this idea, what problems need to be solved, which code parts will need an update and so one. Than I could try to get it working, but right now, I doesn't even know the right questions. Best regards, - Johannes Kellner -- -- Johannes Kellner freiberuflicher Informatiker Gostritzer Str. 12, 01217 Dresden, Germany Mobil: +49 162 4145161 Home: +49 351 4087058 cont...@johannes-kellner.eu www.johannes-kellner.eu UStId: DE 2568 79021 --
Re: [gentoo-portage-dev] a feature called stabilize wanted
Hello List ans anyone! I'm searching for a feature or an hint how and where to implement it. Mmmm... Im not one of the knowledgable ppl around here but you can have version ranges within files like package.keywords eg cat/A-4.0 which would mean ~arch A-4.0 = arch which is essentially what your asking for. The biggest issue I have with a feature like this is that you seems to be overriding the config files all ready present. That would only last until the next time you ran emerge. I think this could be better solved with tools ( gui or cli ) that allowed a user to manage package.keywords, etc. Now a tool that actually did this would be very interesting indeed. Alistair. The desired feature could be called stabilize or update to stable and would change the selected packages when doing an update (emerge -avuND world). Just to give you an initial idea/example, some packages: package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 So version numbers with the ~ are unstable/~amd64, where numbers without are stable/amd64. Case 1 (amd64): using system wide only stable/amd64 Installing anything would result in a...@3.8 and C,B not installed Case 2 (~amd64): using system wide the unstable/~amd64 keyword Installing anything would result in a...@~3.9 b...@~1.6 c...@~1.1 Case 3 (real world): get it managed with masks and keywords that the major packages are stable, while new features could arrive Installing anything with the result a...@3.8 b...@~1.6 c...@~1.1 Nothing new so far, now new package versions arrive: package A - (the old_stable) has: 3.0 3.4 3.8 ~3.9 NEW: 4.0 ~4.1 package B - (the young_stable) has: ~1.3 ~1.4 ~1.6 NEW: 1.8 ~1.9 package C - (the unstable) has: ~0.6 ~0.8 ~1.1 NEW: ~1.2 ~1.4 So if we now update (emerge -avuND) right now the results are: Case 1 (amd64): Update a...@3.8 to 4.0, B,C not installed Case 2 (~amd64): Update a...@~3.9 to ~4.1, b...@~1.6 to ~1.9, c...@~1.1 to ~1.4 Case 3 (real world): depends on the new set of masks and keywords... much work ahead What I search is the stabilize feature for the update e.g. (emerge -avusND) should result in: Case 1 (amd64): - update a...@3.8 to a...@4.0, because a new stable version updates the old stable version - B, C not installed Case 2 (~amd64): - update a...@~3.9 to a...@4.0 update unstable packages to the stable version when arrived, stop using unstable. - update b...@~1.6 to b...@1.8 update unstable packages to the stable version when arrived, stop using unstable. - update c...@~1.1 to C~1.4 update unstable packages, the never unstable versions. Case 3 (real world): - update a...@3.8 to a...@4.0 update stable package to newer stable version when arrived. - update b...@~1.6 to b...@1.8 update unstable packages to the stable version when arrived, stop using unstable. - update c...@~1.1 to C~1.4 update unstable packages, the never unstable versions. Optional: make is possible to ignore/filter/select the unstable to unstable updates, those might cause trouble. Anyone, could help me? Give me a hint if this would be possible? Any hints where in code this could be implemented? I'm programmer, professional, so if I get the right hints, will invest spare time in this. Also I'll ready to setup and run various tests. But I never before worked at portage... It might be a good start if the people with the Know-How, will start a discussing about this idea, what problems need to be solved, which code parts will need an update and so one. Than I could try to get it working, but right now, I doesn't even know the right questions. Best regards, - Johannes Kellner
