FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Portage Developer

 
 
LinkBack Thread Tools
 
Old 03-09-2010, 09:28 PM
Alistair Bush
 
Default 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
 
Old 03-18-2010, 11:41 AM
"Marijn Schouten (hkBst)"
 
Default 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
 

Thread Tools




All times are GMT. The time now is 03:10 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org