| 1 |
Tomek Lutelmowski wrote: |
| 2 |
> I think these two features would be very nice for server enviroments: |
| 3 |
> |
| 4 |
> 1. For stability reasons, relaying only on "x86" flag is often not sufficient. There are many |
| 5 |
> cases when someone masked package as stable, then, few hours later (after users feedback) its |
| 6 |
> reverted to "~x86". After syncinc portage tree, I never know which packages marked as stable are |
| 7 |
> truly stable and well tested by community. My idea is to include new flag for emerge. For examle: |
| 8 |
> # emerge -pu --stablesince=48h world Would list all packages for upgrade, which has not been |
| 9 |
> changed since 48 hours, so there is low possiblity that this list includes untested packages. |
| 10 |
|
| 11 |
Sounds logical to have this feature. It might simplify life. |
| 12 |
Otherwise, a wrapper script should be able to do the same task. |
| 13 |
But what about security bugfixes then? Always waiting 48h is not good, so you'll end up using |
| 14 |
glsa-check after `emerge -pu --stablesince=48h world` or something. |
| 15 |
|
| 16 |
Or was there an option (or suggestion for such) to emerge to update all packages that are security |
| 17 |
related? |
| 18 |
|
| 19 |
> 2. In all my server instalations, I like to keep portage tree as small as possible - for two |
| 20 |
> reasons: syncinc speed and disk space ussage. Now I can only use RSYNC_EXCLUDEFROM flag in |
| 21 |
> make.conf to exclude portage branches from syncinc. Much more convinient and efficent would be |
| 22 |
> RSYNC_INLCUDEFROM flag, so I could define which branches of tree I want to sync. The portage tree |
| 23 |
> will be much smaller, and I wouldnt have to remove new branches that I dont need to sync. Of |
| 24 |
> course in longer term such flag would help to lower bandwich usage of rsync servers. |
| 25 |
|
| 26 |
What about going the Apache way: |
| 27 |
|
| 28 |
RSYNC_ORDER="INCLUDE,EXCLUDE" |
| 29 |
RSYNC_INCLUDE="foo" |
| 30 |
RSYNC_EXCLUDE="bar" |
| 31 |
|
| 32 |
That will work in all cases and altgough a bit more difficult to implement, works in all situations, |
| 33 |
as a "standasd" way to represent such situation, and easy to understang for the novice (is it?). |
| 34 |
|
| 35 |
> What do you think about such features? |
| 36 |
Although this is server related, shouldn't it be going to portage devs as well? |
| 37 |
I think one of them are reading this ML. |
| 38 |
|
| 39 |
Kalin. |
| 40 |
-- |
| 41 |
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]| |
| 42 |
+-> http://ThinRope.net/ <-+ |
| 43 |
|[ ______________________ ]| |
| 44 |
|
| 45 |
-- |
| 46 |
gentoo-server@g.o mailing list |
Archives