[gentoo-dev] Re: automatically killing invalid CFLAGS/warning about bad CFLAGS
James Potts wrote: -fvisibility-inlines-hidden not only breaks a number of kde apps afaik (it's filtered now), Again, probably -fvisibility=hidden. Many people have had success building KDE with both flags enabled lately, so maybe that's something that could be revisited when 4.1 goes ~arch. Getting off topic here, so see http://forums.gentoo.org/viewtopic-t-426814.html if you're interested. but it also seems to break SDL (using noflagstrip). -fvisibility-inlines-hidden affects C++ code. libsdl is written in C. ;) It's not broken enough that I'm going to remove it from my global CXXFLAGS, tho, especially since if it breaks something I know about it right away (compile error) and can remove the flag for that package. Right, so you don't find that `sleep 5` at the beginning of every single emerge just a little annoying? ;) --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On 4/26/06, Kevin <[EMAIL PROTECTED]> wrote: > I'd like to have the capability of being able to list some packages that > should > never be upgraded automatically (I realize I can do this to some degree > already > with portage), some others that are very unlikely to break from an automated > upgrade and thus should always be upgraded automatically, and some packages So maybe this could be satisified by allowing user-defined categories of packages beyond system and world? Something like world, system, fragile, non-fragile? I think you could probably implement something like this yourself with a bit of trickery with the /var/lib/portage/world list. You could copy world to non-fragile, remove anything that you consider fragile from it, and then do an "automatic" update with: cp /var/lib/portage/world /var/lib/portage/world.bak cp /var/lib/portage/non-fragile /var/lib/portage/world emerge -DNuv world cp /var/lib/portage/world.bak /var/lib/portage/world A similar script for the fragile packages would let you update those as a group, obviously using the -p and/or --ask options as you like. Going back to -user now... -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
Mike Frysinger wrote: On Wednesday 26 April 2006 22:38, Donnie Berkholz wrote: Daniel Goller wrote: I like the idea. (But i guess you figured that out already ;) To make it easy, we could just s/herd/team/. then you might as well just keep herd and discard team altogether Yeah, pretty much it would be saying "herds are now teams, but not all teams maintain packages." Donnie -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Version bumps, keywords and you
Hello fellow developers, It's that time of the where I send off an email reminding people on what not to do when bumping versions of packages when it comes to keywords. 1) Please do not drop arch keywords without notifying the arch teams of why (bugs are often the preferred notification method). 2) If possible, attempt to work with us before dropping our keywords. We normally don't bite unless people miss the above steps or the developer's nickname is geoman. In the really off chance that you've just had a run-in with a Vorgon poetry session and are thinking that this email is really for the birds, please consult your friendly neighborhood developer handbook as this is all in there too. Remember, only you can save the goats from jforman. Thanks, -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Wednesday 26 April 2006 22:38, Donnie Berkholz wrote: > Daniel Goller wrote: > > I like the idea. (But i guess you figured that out already ;) > > To make it easy, we could just s/herd/team/. then you might as well just keep herd and discard team altogether -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
Daniel Goller wrote: I like the idea. (But i guess you figured that out already ;) To make it easy, we could just s/herd/team/. Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seemant Kulleen wrote: >> Is there a reason for this besides the definitions not falling into >> place as they should? I'm not seeing a benefit from this to be honest. >> People refer to teams as herds a lot of the time. It has become a >> statement over time that people understand. I'm not sure why we want to >> try and change that to something else, even if that was what it was >> supposed to mean to begin with. > > It's a niggling thing and nothing major as such. But ideas flow from > concepts. And the idea that developers are in herds is not a solid > concept from which to begin. > > While the Ciaran episode has come to an end, the circumstances that led > to that episode have not changed: mutual respect for fellow developers. > That is the idea. The concept should lay that down: a developer is not > a mindless follower, but a human being and a talented developer worthy > of respect. > > This is a very small issue in the scheme of things, and a small hole to > fill. I'd rather fill it in now :) > > Because it's supposed to be fun, too. > > Thanks, > > Seemant At the very least it carries an interesting message, and is so positive we could all think about it and maybe we could go "cool". I like the idea. (But i guess you figured that out already ;) Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUCVP/aM9DdBw91cRAhwZAJ9iZfCATRYUk6ApxuLaY+aNRIdfJQCeIXXI ZDX5NFtScuc07p8wG52IPYs= =EtMC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
> Is there a reason for this besides the definitions not falling into > place as they should? I'm not seeing a benefit from this to be honest. > People refer to teams as herds a lot of the time. It has become a > statement over time that people understand. I'm not sure why we want to > try and change that to something else, even if that was what it was > supposed to mean to begin with. It's a niggling thing and nothing major as such. But ideas flow from concepts. And the idea that developers are in herds is not a solid concept from which to begin. While the Ciaran episode has come to an end, the circumstances that led to that episode have not changed: mutual respect for fellow developers. That is the idea. The concept should lay that down: a developer is not a mindless follower, but a human being and a talented developer worthy of respect. This is a very small issue in the scheme of things, and a small hole to fill. I'd rather fill it in now :) Because it's supposed to be fun, too. Thanks, Seemant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
Seemant Kulleen <[EMAIL PROTECTED]> said: > Consider this both a rant and a GLEP pre-proposal. When we created the > idea of herds back in the day, there was a clear distinction between a > herd and a team (and a project). Over time, those definitions have > become blurry. I would like emphasise: > > A herd is a group of like *packages* > A team is a bunch of people who share a common goal (sometimes to > maintain a herd of packages). > A herd is also a bunch of mindless beasts who follow each other. > > > To that end, it's been brought up that perhaps the metadata.xml files > are partly to blame, in that they imply that the package is maintained > by a herd. There is not maintainer-team listed, just a herd. > > So, I would like to propose that we make this distinction clearer in the > metadata.xml files. I'm interested in thoughts that people have on > this, but please do cc: me in your response to be assured that I read > it. Is there a reason for this besides the definitions not falling into place as they should? I'm not seeing a benefit from this to be honest. People refer to teams as herds a lot of the time. It has become a statement over time that people understand. I'm not sure why we want to try and change that to something else, even if that was what it was supposed to mean to begin with. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpBsqIgO3rqh.pgp Description: PGP signature
[gentoo-dev] Herds, Teams and Projects
Hi All, Consider this both a rant and a GLEP pre-proposal. When we created the idea of herds back in the day, there was a clear distinction between a herd and a team (and a project). Over time, those definitions have become blurry. I would like emphasise: A herd is a group of like *packages* A team is a bunch of people who share a common goal (sometimes to maintain a herd of packages). A herd is also a bunch of mindless beasts who follow each other. To that end, it's been brought up that perhaps the metadata.xml files are partly to blame, in that they imply that the package is maintained by a herd. There is not maintainer-team listed, just a herd. So, I would like to propose that we make this distinction clearer in the metadata.xml files. I'm interested in thoughts that people have on this, but please do cc: me in your response to be assured that I read it. Thanks, Seemant -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Chris Gianelloni posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 26 Apr 2006 15:27:38 -0400: > I'm sorry, but do your friends call you Duncan? I'll leave it at that. Who, me?No, safe to say, /not/ me. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Thanks for your informative reply, Peter. I think I'll try your method for awhile. I'm sure it's less time consuming than my current method, if perhaps still not ideal, and although I do realize this idea may be an unattainable utopia, by Jean-Francois pointing me to glcu, I'm glad to see that I'm not the only person who would like to see an improvement in this area, and that someone's already been working on it for awhile now. This motivates me to take a look at Michael's code and see if I can help make it still better. And although in my perception the thread speaks for itself, I'd like to apologize to anyone who perceived any of my comments as condescending, for that was not my intent. Perception is an interesting thing in that it depends very heavily on the one doing the perceiving and the author/speaker cannot know everything about all of the possible readers (thus all the possible perceptions/interpretations). I did my best to be clear and to the point and not intentionally condescending, using examples to elaborate, and I did not deliberately misunderstand anything. Above all else, I wish to make it clear that IMO, after fiddling with many different Linux distros for more than 10 years, the Gentoo developers have got the closest that I've seen to reaching that utopia. Very nice work, folks, and thank you very much for making such a terrific distro. -Kevin -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On Wed, 26 Apr 2006 15:30:35 -0400, Kevin wrote:
> Jean-Francois Gagnon Laporte wrote:
>> On 4/26/06, Kevin <[EMAIL PROTECTED]> wrote:
>>> What I really want is to make the process of maintaining Gentoo boxes
>>> over the long term easier (IOW: less time-consuming) than is now true,
>>> by adding some functionality that AFAICT does not now exist which would
>>> allow me to automate some things, turn off automation of other things,
>>> and as the sysadmin, have control over what those things should be. In
>>> my mind at least, the central theme in Gentoo of choice dovetails nicely
>>> with what I'm trying to describe here: control and choice that is highly
>>> fine-tunable by the owner of the box in regards to package upgrades.
>>
>> Have a look at GLCU (http://www.panhorst.com/glcu/). Might not be the
>> perfect solution for your needs but it might help. Tools like this
>> one, /etc/portage and a private overlay for testing and/or pinning
>> would be pretty usefull for you right now. Might want to check GLEP 19
>> IIRC for the enterprise tree idea.
>
> Thanks very kindly for your reply and pointer, Jean-Francois!
>
> -Kevin
PMFJI. It seems you want the best of both worlds, and as such are asking a
lot! I fully understand your desire, but IMHO, you can come very close,
but never achieve your stated goal. FWIW, here's what I do.
I have a daily cron job which simply does:
emerge -puNDvt --nospinner world >/home/${MAILTO}/emerge.log
Then, if there is something I don't want to emerge, or a trivial -r?
revision to an ebuild I don't want, I mask it. For example, recently, gcc
went from 3.4.5 to 3.4.5-r1. To me, the change was unnecessary. So I
masked it. There are ways, as previously noted to mask to the major or
minor version, or exclude revisions as well. The problem with that
approach is that a particular revision _COULD_ be important or useful to
you. However, when I do a package.mask entry, I normally use = and mask a
specific version. Using >= is dicey since you would miss an upgrade.
However, from the way I use gentoo, having an automated system would be
quite counterintuitive. Semi-automated? Sure thing. In any event, still
beats the $#^%@ out of RPMs!
Good luck.
--
Peter
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: automatically killing invalid CFLAGS/warning about bad CFLAGS
R Hill gmail.com> writes: > I've yet to hear of _anything_ that's broken because of > -fvisibility-inlines-hidden. (course someone will undoubtedly point > one out now ;)) > -fvisibility-inlines-hidden not only breaks a number of kde apps afaik (it's filtered now), but it also seems to break SDL (using noflagstrip). It's not broken enough that I'm going to remove it from my global CXXFLAGS, tho, especially since if it breaks something I know about it right away (compile error) and can remove the flag for that package. --James -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] General flaming guidelines ;-)
On Wed, 2006-04-26 at 15:55 -0400, Kevin wrote: > Which is it, Chris? You've taken that out of context ... > Make up your mind... I think he has, but wasn't able to communicate his ideas to you in an adequte way > For all the credit that I give to the Gentoo developers, you are one > from whom I would withdraw it. You are merely a polarity responder and > as such, not worth engaging any further. You would do Gentoo a service > by keeping your mouth shut in response to posts like mine (and many > others I'm sure). If I were not so self-assured, you would simply drive > me away from Gentoo with such ugly remarks, and I've no doubt that you > have driven away many others who are less self-assured. Dude ... calm down. Seriously. Insulting or angering us won't help anything and will only make us ignore any good ideas you may have. Your condescending tone makes me want to ignore anything you say ... > You're in my kill file now, so don't waste your time and the bandwidth > by responding. All mailing lists have a topic and attempting to > ridicule other people is not on-topic in any of them... certainly not > here. It just facilitates making you look like a jerk which you need no > assistance with. Deliberately misunderstanding people and then yelling at them is also not something that's on-topic for a mailinglist. In the last two weeks or so I've seen many users that ignore advice, feel insulted at every turn and are not cooperative in any way. This is frustrating and makes those of us who interact with users irritated. I really wish we could have a level-headed discussion instead of insulting, insinuating and trying to annoy people. If you feel that a developer is uncooperative, that you don't get the attention you deserve ... if you have any idea how to make things better, send a mail to [EMAIL PROTECTED] Please don't take your frustrations out on developers, let us try to fix the problem. I hope that we can help you resolve any conflicts you may or may not have. wkr, Patrick, UserRel Monkey -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
zing ! and with this post it's probably best to let this subthread die before we get any more offtrack -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Chris Gianelloni wrote: >Honestly, I don't see portage ever being able to really > support anything like this so long as the tree continues to change. > It simply doesn't seem to be compatible with how Gentoo development is > done. and Chris Gianelloni wrote: > > Yup. It's called /etc/portage and we've had it for a while. You simply > seem to be missing its flexibility. > Yep. It was such a good idea that the portage team implemented it quite > some time ago. *grin* > Which is it, Chris? Impossible that portage will ever be able to really support anything like this... or... already done and I (along with Jean-Francois and Michael Schilling) am just too stupid to see it? Make up your mind... For all the credit that I give to the Gentoo developers, you are one from whom I would withdraw it. You are merely a polarity responder and as such, not worth engaging any further. You would do Gentoo a service by keeping your mouth shut in response to posts like mine (and many others I'm sure). If I were not so self-assured, you would simply drive me away from Gentoo with such ugly remarks, and I've no doubt that you have driven away many others who are less self-assured. You're in my kill file now, so don't waste your time and the bandwidth by responding. All mailing lists have a topic and attempting to ridicule other people is not on-topic in any of them... certainly not here. It just facilitates making you look like a jerk which you need no assistance with. -Kevin -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Jean-Francois Gagnon Laporte wrote: > On 4/26/06, Kevin <[EMAIL PROTECTED]> wrote: >> What I really want is to make the process of maintaining Gentoo boxes >> over the long term easier (IOW: less time-consuming) than is now true, >> by adding some functionality that AFAICT does not now exist which would >> allow me to automate some things, turn off automation of other things, >> and as the sysadmin, have control over what those things should be. In >> my mind at least, the central theme in Gentoo of choice dovetails nicely >> with what I'm trying to describe here: control and choice that is highly >> fine-tunable by the owner of the box in regards to package upgrades. > > Have a look at GLCU (http://www.panhorst.com/glcu/). Might not be the > perfect solution for your needs but it might help. Tools like this > one, /etc/portage and a private overlay for testing and/or pinning > would be pretty usefull for you right now. Might want to check GLEP 19 > IIRC for the enterprise tree idea. Thanks very kindly for your reply and pointer, Jean-Francois! -Kevin -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On Wed, 2006-04-26 at 14:24 -0400, Kevin wrote: > And unless I'm way off-base, the version-difference-threshold notion > described above is not implemented in portage now. Someone please > correct me if I'm wrong. You're off-base. See, you can, for example, mask all revisions within the same version of a package in your /etc/portage/package.mask file quite easily. So you *could* have xemacs, using your own example, only ask to upgrade once the stable version in the tree went over a certain threshold. > Well your comment is certainly true in the most extreme interpretation, > but the same thing can be accurately said about whether or not one > should assume that the sun is going to rise tomorrow or that the > universe won't disappear in a quantum fluctuation while you're sleeping, > but IMO, such extreme statements have little value in day-to-day > application. Everyone must make some assumptions about nearly > everything or it becomes nearly impossible to function. I make all > kinds of assumptions in administering computers and they almost always > make my life much, MUCH easier than it would be without the assumptions. I'm sorry, but do your friends call you Duncan? I'll leave it at that. > Sometimes they bite me, but only rarely. The key to success here is > having the judgment to know what is relatively safe to make assumptions > about and what is not. Judgment is something that only a human can > provide... not a computer. This is why I want greater and more granular > control over upgrading packages in Gentoo. Aside from the points you > make above (and I may be missing some other features currently present > in Gentoo), my choices now are, in the grossest terms: upgrade every > package by hand, one at a time, while sitting in front of the computer > (which is very close to what I spent last weekend doing) or do an emerge > world and hope for the best. IMO, that's not much control and does not > allow for the application of judgment except in the former option (which > is very, very time consuming). You missed the ability to lock down to specific package versions, which is already a 100% possibility with current portage. You can lock down the versions to *anything that you want* via package.mask and package.unmask, then simply have your system run an "emerge --update --deep world" to automatically upgrade any and all packages not listed in your mask files. > What I really want is to make the process of maintaining Gentoo boxes > over the long term easier (IOW: less time-consuming) than is now true, > by adding some functionality that AFAICT does not now exist which would > allow me to automate some things, turn off automation of other things, > and as the sysadmin, have control over what those things should be. In > my mind at least, the central theme in Gentoo of choice dovetails nicely > with what I'm trying to describe here: control and choice that is highly > fine-tunable by the owner of the box in regards to package upgrades. Yup. It's called /etc/portage and we've had it for a while. You simply seem to be missing its flexibility. > I'm not a member of the portage-devel mailing list so I'm going to drop > this now. If someone here is a member of both, then please feel free to > cross-post this thread to whatever forum is most appropriate for it. > After spending 30-45 minutes trying to help improve Gentoo by posting a > new (AFAICT) idea in bugzilla and again here, I feel like I've done > enough. IMHO, this is an idea that would add great value to Gentoo and > I can't help but think that many sysadmins who must maintain many boxes > would agree, but I have no particular attachment to the idea that would > make me want to go around every mailing list under the sun trumpeting my > idea to anyone who will listen. I'm just posting an idea that seemed > like a good one to me. The devs may take it or leave it as they see fit. Yep. It was such a good idea that the portage team implemented it quite some time ago. *grin* -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On 4/26/06, Kevin <[EMAIL PROTECTED]> wrote: > > What I really want is to make the process of maintaining Gentoo boxes > over the long term easier (IOW: less time-consuming) than is now true, > by adding some functionality that AFAICT does not now exist which would > allow me to automate some things, turn off automation of other things, > and as the sysadmin, have control over what those things should be. In > my mind at least, the central theme in Gentoo of choice dovetails nicely > with what I'm trying to describe here: control and choice that is highly > fine-tunable by the owner of the box in regards to package upgrades. > > > Regards, > Kevin > -- Have a look at GLCU (http://www.panhorst.com/glcu/). Might not be the perfect solution for your needs but it might help. Tools like this one, /etc/portage and a private overlay for testing and/or pinning would be pretty usefull for you right now. Might want to check GLEP 19 IIRC for the enterprise tree idea. Regards, Jean-Francois -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Chris Gianelloni wrote: > On Wed, 2006-04-26 at 12:29 -0400, Kevin wrote: >> One thing that I'm pretty sure is currently not possible with portage, >> however, and that I'd definitely like to see as a part of this idea is a >> way of setting thresholds on version numbers of packages in portage such >> that the automated upgrade system will only upgrade a package >> automatically if the difference in version numbers between the installed >> package and the newest available package in portage is greater than some >> admin-tunable amount. For example, I might not want to upgrade emacs or >> xemacs just because a new -r number becomes available. Maybe I don't >> want to have such a big package upgraded automatically unless there is a >> new major or minor version number. >> >> Thanks again to all the developers who have made Gentoo. It's a really >> terrific distro. > > Jakub meant the portage-devel mailing list, not this one. woops. when i saw portage/devel i figured one or the other... guess not... > > Anyway, most of this can be done already using /etc/portage files and > some well-written cron scripts. You can lock down versions of specific > packages quite easily using your own package.mask and package.unmask > files, along with package.keywords. Yes, and as I wrote, I'm aware of your points here, and I do use these capabilities fairly extensively now, but it is not the sort of fine-tunable system that I have in mind where I could inform the automated-update-system (for lack of a better name) of my wishes in terms of which packages are safe (in my judgment, as the sysadmin of that particular box) to upgrade in an unattended manner and which are not (at least, not unless I'm much less well-informed on Gentoo than I believe myself to be, which I'm not denying might be true). And unless I'm way off-base, the version-difference-threshold notion described above is not implemented in portage now. Someone please correct me if I'm wrong. > However, one thing you can *never* > do is assume that *any* package that has *any* kind of configuration > files or is a library will *never* change in an incompatible way. Well your comment is certainly true in the most extreme interpretation, but the same thing can be accurately said about whether or not one should assume that the sun is going to rise tomorrow or that the universe won't disappear in a quantum fluctuation while you're sleeping, but IMO, such extreme statements have little value in day-to-day application. Everyone must make some assumptions about nearly everything or it becomes nearly impossible to function. I make all kinds of assumptions in administering computers and they almost always make my life much, MUCH easier than it would be without the assumptions. Sometimes they bite me, but only rarely. The key to success here is having the judgment to know what is relatively safe to make assumptions about and what is not. Judgment is something that only a human can provide... not a computer. This is why I want greater and more granular control over upgrading packages in Gentoo. Aside from the points you make above (and I may be missing some other features currently present in Gentoo), my choices now are, in the grossest terms: upgrade every package by hand, one at a time, while sitting in front of the computer (which is very close to what I spent last weekend doing) or do an emerge world and hope for the best. IMO, that's not much control and does not allow for the application of judgment except in the former option (which is very, very time consuming). > > Basically, what you want is the assurances of a binary distribution that > things will "just work" when upgraded, No. Not true at all. And for that matter, binary distributions (in my 10+ years of experience with them) simply do NOT just work: not for Slackware, not for Yellowdog, not for SuSE, not for Redhat, nor Mandrake, nor any of a dozen others I've tried. I found that quite the opposite was true which was one of the reasons I switched to Gentoo (which I've found, usually DOES just work after upgrades; not always, but usually---and this is a credit to the Gentoo developers). What I really want is to make the process of maintaining Gentoo boxes over the long term easier (IOW: less time-consuming) than is now true, by adding some functionality that AFAICT does not now exist which would allow me to automate some things, turn off automation of other things, and as the sysadmin, have control over what those things should be. In my mind at least, the central theme in Gentoo of choice dovetails nicely with what I'm trying to describe here: control and choice that is highly fine-tunable by the owner of the box in regards to package upgrades. I'm not a member of the portage-devel mailing list so I'm going to drop this now. If someone here is a member of both, then please feel free to cross-post this thread to whatever forum is most appropriate for it. After spending 30-45 minutes
Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On Wed, 2006-04-26 at 12:29 -0400, Kevin wrote: > One thing that I'm pretty sure is currently not possible with portage, > however, and that I'd definitely like to see as a part of this idea is a > way of setting thresholds on version numbers of packages in portage such > that the automated upgrade system will only upgrade a package > automatically if the difference in version numbers between the installed > package and the newest available package in portage is greater than some > admin-tunable amount. For example, I might not want to upgrade emacs or > xemacs just because a new -r number becomes available. Maybe I don't > want to have such a big package upgraded automatically unless there is a > new major or minor version number. > > Thanks again to all the developers who have made Gentoo. It's a really > terrific distro. Jakub meant the portage-devel mailing list, not this one. Anyway, most of this can be done already using /etc/portage files and some well-written cron scripts. You can lock down versions of specific packages quite easily using your own package.mask and package.unmask files, along with package.keywords. However, one thing you can *never* do is assume that *any* package that has *any* kind of configuration files or is a library will *never* change in an incompatible way. Basically, what you want is the assurances of a binary distribution that things will "just work" when upgraded, yet you still want the power of Gentoo. Honestly, I don't see portage ever being able to really support anything like this so long as the tree continues to change. It simply doesn't seem to be compatible with how Gentoo development is done. Then again, I could be completely off my rocker and the portage team might already have all of this implemented in some super-secret internal-only version. As I said, this would probably be best conversed with them on the portage-devel list. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Pasted from bugzilla. Please pardon the ugly newline formatting. I'm a longtime (>10 yrs) Linux admin and I've been using Gentoo for perhaps 2 years and I'm super impressed with Gentoo, having gotten very annoyed with the rpm-based nightmare upgrade situation presented by most of the other distros, but one thing I'd really like to see in Gentoo is a way of safely keeping my Gentoo boxes up to date in an automated way. I know that may sound paradoxical and mutually contradictory. I realize that production systems should not be upgraded before trying out the upgrade on a testbed system, but I've found that routine cron jobs of emerge world are unsafe because some packages need a human's attention for upgrading (like apache or postfix when config files should be left untouched or updated or merged with new config files or some other issue that needs a human's attention) whereas doing nothing for a long time (while the portage tree evolves) makes for a box that has been veritably left behind, sometimes making it difficult or impossible to upgrade. I'd like to have the capability of being able to list some packages that should never be upgraded automatically (I realize I can do this to some degree already with portage), some others that are very unlikely to break from an automated upgrade and thus should always be upgraded automatically, and some packages (which may fit in either or both of these categories) that must be upgraded in a certain order in order to avoid breaking something and thus, should probably be upgraded automatically or (if flagged for preventing automatic upgrades by the admin) should be brought to the attention of the admin (say with an email to root or something) as needing attention to avoid breakage. I am asking for this feature after having spent an entire weekend upgrading various packages by hand, one or a few at a time, after carefully considering whether or not it would be safe to upgrade this or that package, and after having (lazily) not upgraded anything on this production box in a long time. The experience has left me rather exhausted (with a sore ass from sitting down for so long) and wishing for something better. One noteworthy experience in particular is that I found that many packages suffered sandbox violations on attempted upgrades, and I troubleshot this problem for a long time before it occurred to me that I might want to upgrade the sandbox package and then try upgrading these packages. That solved the sandbox violation problem. It seems to me that this was a case where an automated system could have insisted on upgrading the sandbox package first, before the others. Perhaps there should have been a dependency, so that when I tried to upgrade the ncurses library, it automatically pulled in the newer sandbox package as a prerequisite (for that is what it turned out to be). After writing this much, it occurs to me that perhaps the capabilities that I describe here may already be in Gentoo/portage in some way that I've yet to fully discover and/or utilize, but despite having installed many Gentoo systems and read the Handbook (and many other Gentoo docs) many times, I've yet to see a good write-up on how to do what I describe here. And perhaps the fact that the sandbox package was not a dependency for the ncurses package (and several others that also broke during emerge with sandbox violations) was the real "bug" so to speak, rather than the idea that Gentoo is missing this major feature that I'm asking for. I'm really not sure which might be true, but I just thought I'd ask. One thing that I'm pretty sure is currently not possible with portage, however, and that I'd definitely like to see as a part of this idea is a way of setting thresholds on version numbers of packages in portage such that the automated upgrade system will only upgrade a package automatically if the difference in version numbers between the installed package and the newest available package in portage is greater than some admin-tunable amount. For example, I might not want to upgrade emacs or xemacs just because a new -r number becomes available. Maybe I don't want to have such a big package upgraded automatically unless there is a new major or minor version number. Thanks again to all the developers who have made Gentoo. It's a really terrific distro. --- Comment #1 From Radek Podgorny 2006-04-24 08:25 PST [reply] --- Maybe, the packages themselves could be assigned something like a safe-upgrade-flag... --- Comment #2 From Jakub Moc 2006-04-26 08:46 PST [reply] --- Please, take such ideas to portage/devel mailing lists... Bugzilla is not the best place to discuss abstract ideas. Thanks. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Gentoo theming during bootup
Matthew Gaule posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 25 Apr 2006 21:55:13 +: > Could a simple USE flag (Such as "branding") be implemented, which if set, > will pull in and configure gentoo themes when a package is compiled? This > could be unset by default, meaning most users would not be effected by > this. If the suggestion is to be taken, perhaps "gentoo-branding" would be a clearer USE flag? Simply "branding" to me indicates upstream branding, say all the things necessary to have a real Firefox (TM) registered browser, icon and theming complete as upstream, instead of the Gentoo version with various (unapproved upstream) Gentoo patches. In theory, people should read the USE description, but I don't think we need a repeat of the gtk/gtk2 confusion. =8^P -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Purpose of USE=doc
Jakub Moc posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 25 Apr 2006 20:03:00 +0200: > I'd like to see some clarification of intended doc use flag usage, so that > we wouldn't force users to download/install 40+ megs of docs for a ~3 meg > package, with the only reason being that USE=doc is for developer > documentation only. [1] > > And no, I don't think we need yet another use flag. ;) FEATURES="nodoc" is > also not exactly useful as it's forcing users to download stuff they are > not interested in at all. (To make it more clear, I'm talking about > ebuilds that download docs in a separate tarball here.) > > [1] http://bugs.gentoo.org/show_bug.cgi?id=122265 Maybe I'll get shot down for this, but IMO, there's nothing wrong with individual packages having a local userdoc USE flag. I don't believe it needs to be global, and in the general case its use would be discouraged, but it seems reasonable in extreme cases like the above, where the docs tarball is ten times the size of the source tarball. Maybe make it a policy that the flag is only to be used when docs are a minimum of three times (or twice?) the source tarball size and at least 10 MB, and then dev discretion is advised? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
