[EMAIL PROTECTED] writes: > Richard Watson said: >> "Matthias F. Brandstetter" <[EMAIL PROTECTED]> writes: >> IMO this kind of upgrade should happen on purpose because someone >> chose to do it, not as the result of emerge -u. > > But emerge -u IS on purpose.
What I mean is that I want to do major upgrades when I'm ready, not when the package maintainers decide that I'm ready. I'm only talking here about upgrades that may break the application concerned which is not very often. I agree that the admin is responsible, I carefully read every list of potential upgrades before I commit, but I think it would be a good safety measure to not allow things to upgrade where potential breakages might occur. That seems to me to be allowing portage to make life a little easier for the admin. > Nobody just has that in their cron to run every night. (At least I > HOPE nobody does) Quite. > Shouldn't it be the admin's responsibility to make sure he/she knows > what packages are being upgraded BEFORE the upgrade? Why must > portage save them from themselves? I'm not suggesting this. What I'm saying is that it doesn't make sense to unnecessary upgrades which may break something the default action. > BTW, there is a simple and well publicized way to avoid this problem. > (I've done it on 9 of my 10 gentoo servers) simply populate package.mask > with the proper info. Maybe I do the wrong thing but I've been using /etc/make.profile/packages wherein it says: # So, what happens to /usr/portage/profiles/package.mask? It's still around, # and still useful. But it should mainly be used for broken ebuilds only. # package.mask continues to function as normal, masking out ebuilds from *all* # system profiles. > Sorry but I disagree with you. Apache 2 is not a different product. It's a > major version change to Apache. (Same with mysql and PHP) It applies to different applications to different extents. In the case of vmware everyone who upgrades will have their installation broken until they go to purchase a licence. They are clearly therefore different products since they are not covered by the same license. I think it all boils down to whether you think that checking through lists of packages is reliable enough and how much portage should help the admin. I think most professional admins will know about many upgrades before they arrive enough to know whether they want them or not and to have prepared accordingly. But since we have many duplicated ebuilds - (e.g. gaim and gaim-cvs, mozilla-firebird, mozilla-firebird-cvs) to make life convenient for those who want to stay on the cutting edge, could a little reorganisation not make it more convenient for those of us who don't? -- Richard Watson http://www.opencolo.com/ High Value Colocation -- [EMAIL PROTECTED] mailing list
