| 1 |
On Mon, 25 Dec 2006 11:46:23 +0300, Mike Myers <fluffymikey@×××××.com> |
| 2 |
wrote: |
| 3 |
|
| 4 |
> I understand what you say, but I'm not sure I got my point across very |
| 5 |
> well. Let's say I have a server that has various things installed like |
| 6 |
> apache with the 2.0 branch, mysql with the 4.0 branch, and PHP with |
| 7 |
> the 4.xbranch. If I do an emerge -u world on a machine with these, at |
| 8 |
> some random |
| 9 |
> point in time when the devs decide the newer branch is stable, then any |
| 10 |
> one |
| 11 |
> of these will be upgraded to the next branch. What I am asking, is why |
| 12 |
> wouldn't it be better to have it where I will only stay on the current |
| 13 |
> branch for that profile, and only move to the next branch when I change |
| 14 |
> the |
| 15 |
> profile? |
| 16 |
> |
| 17 |
|
| 18 |
I do not see any linkage between a profile, which is actually just a set |
| 19 |
of use variables , and application versions since there is no version data |
| 20 |
in a profile. (Actually there is, like minimal package versions and |
| 21 |
required stage 1 packages, but adding maximum versions to profile will |
| 22 |
make it unusable for most users) That is, profile is not a branch. |
| 23 |
|
| 24 |
I also do not see how a branch can be created based on a profile or a |
| 25 |
snapshot of a portage tree. For example, if a server profile is being |
| 26 |
used, what PHP should be in the branch? Or, better, if I decide to install |
| 27 |
Qt on a server, which definitely does not have KDE, should it be 3 or 4? |
| 28 |
The only base for branch type versioning I see is the current set of |
| 29 |
installed packages. |
| 30 |
|
| 31 |
You want to update world and, at the same time, not to update anything. I |
| 32 |
can understand that if your goal is not to "update world", as Portage |
| 33 |
thinks when you say "-u world", but to install only bug and sequrity |
| 34 |
fixes, as Portage does if you mask pakeges properly. As far as I remember, |
| 35 |
according to this list some work to treat sequrity updates differently is |
| 36 |
under way. As for bug fixes, I do not see how they can be separated from |
| 37 |
features. |
| 38 |
|
| 39 |
I feel that what you call "branch" Portage often calls "slot". For |
| 40 |
example, PHP is slotted, so that if you have PHP 4 and PHP 5 is being |
| 41 |
installed, your 4 does not go away. |
| 42 |
|
| 43 |
As for ebuilds going modular, I beleive that each case is to be treated |
| 44 |
separately. For example, KDE is going modular now. For 3, both modular and |
| 45 |
monolithic ebuilds are maintained, for 4 - only modular ones. No problems |
| 46 |
at all, right? |
| 47 |
|
| 48 |
I still do not see that any changes to portage are necessary. My guess is |
| 49 |
that your request can be formulated as a set of requests like |
| 50 |
|
| 51 |
- this app is not slotted, it should be |
| 52 |
|
| 53 |
- I want a script that will examine my world and mask everything so that I |
| 54 |
can upgrade only the last 2 version numbers |
| 55 |
|
| 56 |
- I want another script to manage the masks set by the previous one |
| 57 |
|
| 58 |
I hope that will be easier for developers to understand. |
| 59 |
|
| 60 |
-- |
| 61 |
Andrei Gerasimenko |
| 62 |
-- |
| 63 |
gentoo-user@g.o mailing list |
Archives