Re: [gentoo-user] Things that can be improved
* Rafael Fernández López [EMAIL PROTECTED] wrote: snip The first thing that I'd change is etc-update or dispatch-conf. I'd thanks for the tip to dispatch-conf. Again learned something new :) This is what I was just looking for. BTW: if you change some config file by hand, it's seems wise to add some comment, so you always get a hint in the diff. BTW#2: is there any option to diff trim off ending whitespaces on each line before comparing ? I sometimes see changed lines where I actually can't see any difference, so there're probably just some ending whitespaces added/removed. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Thu, 27 Jul 2006 15:34:52 +0200, Enrico Weigelt wrote: BTW#2: is there any option to diff trim off ending whitespaces on each line before comparing ? I sometimes see changed lines where I actually can't see any difference, so there're probably just some ending whitespaces added/removed. # Automerge files comprising only whitespace and/or comments # (yes or no) replace-wscomments=yes in /etc/dispatch-conf.conf -- Neil Bothwick System halted - Press all keys at once to continue. signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
On Sun, Jul 09, 2006 at 05:29:06PM +0200, Alexander Skwar wrote Gerhard Hoogterp schrieb: When I say yes I mean yes. When I say no I mean no. And I don't mean just until the next update either. I have reasons for my settings; please don't act like Windows and assume that you know better than me. And there is no excuse whatsoever for wiping out the custom settings in /etc/conf.d/local.start As I wrote in an other mail: Stop interfering with the actual configfile and add the changes to a config.conf.dist file. Yep, you wrote that, and I answered that *I* would *NOT* like this. I like it, that I can use a program right away - at least in a default way. If you had your way, *NO* program which relied on configuration files would be usable after installation, as no configuration file could be found. Because of that, I would not want to happen what you proposed. I think there's a mis-understanding here. Gerhard and I are complaining about config files being possibly *OVERWRITTEN* with default settings. If there's no config file, sure write the default config file. But if someone has customized a config file, assume that they know what they're doing, and leave settings alone. -- Walter Dnes [EMAIL PROTECTED] In linux /sbin/init is Job #1 My musings on technology and security at http://tech_sec.blog.ca -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Walter Dnes wrote: I think there's a mis-understanding here. Gerhard and I are complaining about config files being possibly *OVERWRITTEN* with default settings. If there's no config file, sure write the default config file. But if someone has customized a config file, assume that they know what they're doing, and leave settings alone. And that's what's currently happening - the settings are left alone, *UNLESS* you make etc-update overwrite your original file. But generally, the files are *NOT* touched. Alexander Skwar -- My father taught me three things: (1) Never mix whiskey with anything but water. (2) Never try to draw to an inside straight. (3) Never discuss business with anyone who refuses to give his name. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Alexander Skwar wrote: Walter Dnes wrote: I think there's a mis-understanding here. Gerhard and I are complaining about config files being possibly *OVERWRITTEN* with default settings. If there's no config file, sure write the default config file. But if someone has customized a config file, assume that they know what they're doing, and leave settings alone. And that's what's currently happening - the settings are left alone, *UNLESS* you make etc-update overwrite your original file. But generally, the files are *NOT* touched. Alexander Skwar Correct. I can remember when it used to try to overwrite fstab every time, well, it seemed like it anyway. It doesn't do that anymore though. It puts the new file there but the one we, the person in the chair, changed does not get touched until you run etc-update and tell it to change it. Careful with that -5 option. Sounds like some are not using etc-update correctly. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Dale wrote: Careful with that -5 option. delta ~ # ( while true ; do echo -5\n ; done ) | etc-update *shifty eyes* -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/11/06, Walter Dnes [EMAIL PROTECTED] wrote: On Sun, Jul 09, 2006 at 05:29:06PM +0200, Alexander Skwar wrote Gerhard Hoogterp schrieb: When I say yes I mean yes. When I say no I mean no. And I don't mean just until the next update either. I have reasons for my settings; please don't act like Windows and assume that you know better than me. And there is no excuse whatsoever for wiping out the custom settings in /etc/conf.d/local.start As I wrote in an other mail: Stop interfering with the actual configfile and add the changes to a config.conf.dist file. Yep, you wrote that, and I answered that *I* would *NOT* like this. I like it, that I can use a program right away - at least in a default way. If you had your way, *NO* program which relied on configuration files would be usable after installation, as no configuration file could be found. Because of that, I would not want to happen what you proposed. I think there's a mis-understanding here. Gerhard and I are complaining about config files being possibly *OVERWRITTEN* with default settings. If there's no config file, sure write the default config file. But if someone has customized a config file, assume that they know what they're doing, and leave settings alone. That only happens if YOU do it. No config file is EVER changed without your permission by portage, if it does not exist, a default is copied, but if there's already one, no. Another thing, some programs will NOT WORK AT ALL if you do not update your config files, been there, done that. If your program, in its evolution process, increases security, changes some variable names, change its behavior in any way while dealing with config files, and you keep your old config, you're in trouble. Gentoo gives you the new format config file, so you can merge changes interactively, avoiding problems and keeping your config up-to-date. What other config file protection does that?! -- Walter Dnes [EMAIL PROTECTED] In linux /sbin/init is Job #1 My musings on technology and security at http://tech_sec.blog.ca -- gentoo-user@gentoo.org mailing list -- Daniel da Veiga Computer Operator - RS - Brazil -BEGIN GEEK CODE BLOCK- Version: 3.1 GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V- PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++ --END GEEK CODE BLOCK-- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/9/06, Alexander Skwar [EMAIL PROTECTED] wrote: WouldPORTAGE_ELOG_MAILURI=[EMAIL PROTECTED] user:[EMAIL PROTECTED]:pass_with_:[EMAIL PROTECTED]@mailserver:port work? For clarification:user= user:[EMAIL PROTECTED]pass=pass_with_:[EMAIL PROTECTED]mailserver=mailserverport=port Well, ymmv, but assuming the mailer parses the uri the same way HTTP does, You would have to percent encode the character with special meanings: So, it would be more like this: user=user%3Aname%40bsp.invalidpass=pass_with_%3A_colon%40domainmailserver=mailserverport=portYeilding: PORTAGE_ELOG_MAILURI=\ [EMAIL PROTECTED] user%3Aname%40bsp.invalid:[EMAIL PROTECTED]:port (Line break added to discourage wrapping)dcm
Re: [gentoo-user] Things that can be improved
I think there's a mis-understanding here. Gerhard and I are complaining about config files being possibly *OVERWRITTEN* with default settings. If there's no config file, sure write the default config file. But if someone has customized a config file, assume that they know what they're doing, and leave settings alone. That only happens if YOU do it. No config file is EVER changed without your permission by portage, if it does not exist, a default is copied, but if there's already one, no. Sure and if Ihad lots of time I would do an emerge world every day just to check a few files. Regretfully, with 5 servers, some 28 websites and some other work too I don't have that daily time. So when I update my system I have to go through pages full of diffs, checking every diff to see if, besides all the settings returning to default, there are also changes that I should be aware off. A wrong key is easily pressed and there you go.. And why? Yes I changed my settings and yes etc-update or dispatch-conf show me carefully every moved point or comma. Thanks, but I know I changed those and I did that on purpose. Untouched files are already on auto-pilot. Show me what is added or removed. And since it can only do that by comparing the new file to a clean, untouched, original file I innocently suggested to have such a file, make changes there and leave it up to the admin to check if settings are added or removed and deal with these changes in the active config file.. And in that case don't bother showing the diff.. just tell me which files have changed and *offer* to show the changes. But don't touch my active configes.. not automatically, not ever.. Guess I'm just paranoid.. but then again, sometimes a healty amount of paranoia keeps you out of a lot of troubles.. Gerhard -- Ithaka photography, http://ithaka.mine.nu/ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Gerhard Hoogterp schrieb: I think there's a mis-understanding here. Gerhard and I are complaining about config files being possibly *OVERWRITTEN* with default settings. If there's no config file, sure write the default config file. But if someone has customized a config file, assume that they know what they're doing, and leave settings alone. That only happens if YOU do it. No config file is EVER changed without your permission by portage, if it does not exist, a default is copied, but if there's already one, no. Sure and if Ihad lots of time I would do an emerge world every day just to check a few files. Regretfully, with 5 servers, some 28 websites and some other work too I don't have that daily time. So when I update my system I have to go through pages full of diffs, checking every diff to see if, besides all the settings returning to default, there are also changes that I should be aware off. Maybe you should also be aware of changed defaults. A wrong key is easily pressed and there you go.. ...to get your backup. What's the problem? You *DO* have backups, don't you? It would be quite irresponsible to NOT have backups. But who am I telling that. And why? Yes I changed my settings and yes etc-update or dispatch-conf show me carefully every moved point or comma. Thanks, but I know I changed those and I did that on purpose. Untouched files are already on auto-pilot. The auto-pilot *MIGHT* be bad as well. Maybe a default was changed and the user wants to keep the old default. With an auto-pilot, that's quite hard. But you know that, don't you? Show me what is added or removed. And please also, what's *CHANGED*. And since it can only do that by comparing the new file to a clean, untouched, original file I innocently suggested to have such a file, make changes there and leave it up to the admin to check if settings are added or removed and deal with these changes in the active config file.. And in that case don't bother showing the diff.. just tell me which files have changed and *offer* to show the changes. You *ARE* offered to see the changes. NOTHING's forcing you to see the changes. When you run etc-update, you've got the option to enter 1, 2, 42 to see those changed configuration files. But don't touch my active configes.. not automatically, not ever.. Okay, so you're fine with etc-update, you say? Alexander Skwar -- Yow! Now we can become alcoholics! -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Hi, On Tue, 11 Jul 2006 21:07:42 +0200 Gerhard Hoogterp [EMAIL PROTECTED] wrote: Show me what is added or removed. And since it can only do that by comparing the new file to a clean, untouched, original file I innocently suggested to have such a file, make changes there and leave it up to the admin to check if settings are added or removed and deal with these changes in the active config file.. And in that case don't bother showing the diff.. just tell me which files have changed and *offer* to show the changes. But don't touch my active configes.. not automatically, not ever.. Hm, OK, *now* I understand your point. You want to track your own, hand made changes that don't have anything to do with new versions of default config files except from that you want to show those changes when making your decisions, correct? So basically, you want a three-pane (even better, though I can't image it visually: a tri-angular) view: Old default config, your modified version and new default config, i.e. kind of a diff3 approach. I agree, that would be interesting. Maybe this could easily be archieved with unionfs, having changed files in an overlayed file system. Another option would be to use a full fledged concurrent version system in /etc. Probably RCS might even be sufficient. In fact, if there are still binary packages for the old version of the package that brought in the new config file version, it would even be possible to extract the old default config and use that. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
[Discussion about etc-update (and friends) changing something that was set by the user] I believe there is a misunderstanding. Perhaps what the OP is noting is that etc-update gives you diffs between * The file as on your system (which may have user changes) * The file as in the current emerge of this package I believe he would prefer to know the difference * The file as in the previous emerge of this package * The file as in the current emerge of this package Then he would decide what to do with these changes. I use etc-update but I believe that dispatch-conf can keep an RCS revision history. This should help determine the desired difference. I apologize if it is I who have misunderstood the conversation and am increasing the confusion. allan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Allan Gottlieb wrote: [Discussion about etc-update (and friends) changing something that was set by the user] I believe there is a misunderstanding. Perhaps what the OP is noting is that etc-update gives you diffs between * The file as on your system (which may have user changes) * The file as in the current emerge of this package I believe he would prefer to know the difference * The file as in the previous emerge of this package * The file as in the current emerge of this package Then he would decide what to do with these changes. I use etc-update but I believe that dispatch-conf can keep an RCS revision history. This should help determine the desired difference. I apologize if it is I who have misunderstood the conversation and am increasing the confusion. allan Maybe I have something set different but mine does tell what is going to be changed between the two files and you can select what you want to change or not change. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Allan Gottlieb wrote: I believe he would prefer to know the difference * The file as in the previous emerge of this package * The file as in the current emerge of this package Then he would decide what to do with these changes. Precisely. When Portage makes a ._cfg_* file, it should record this file also in /var/db/pkg/..., and upon the next emerge of that same package, etc-update should show the diff between that file and the new one. Benno -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
At Tue, 11 Jul 2006 16:01:00 -0500 Dale [EMAIL PROTECTED] wrote: Allan Gottlieb wrote: [Discussion about etc-update (and friends) changing something that was set by the user] I believe there is a misunderstanding. Perhaps what the OP is noting is that etc-update gives you diffs between * The file as on your system (which may have user changes) * The file as in the current emerge of this package I believe he would prefer to know the difference * The file as in the previous emerge of this package * The file as in the current emerge of this package Then he would decide what to do with these changes. I use etc-update but I believe that dispatch-conf can keep an RCS revision history. This should help determine the desired difference. I apologize if it is I who have misunderstood the conversation and am increasing the confusion. allan Maybe I have something set different but mine does tell what is going to be changed between the two files and you can select what you want to change or not change. I don't think it is a settings difference. I believe it is giving you the differences between the first two files I listed above and the OP wanted the difference between the last two allan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Friday 07 July 2006 15:22, Rafael Fernández López wrote: Hi, This is not flame war. I love Gentoo, and it is the distribution that fits me perfectly, but I've been wondering this last year what things can be improved in this wonderful distro. snip If I have more ideas I'll tell ya. I've got one. MOST packages you can emerge an update, 'merge' your config files using etc-update or something, and everything is happy. But there are many packages that require more to be done. Some of these are more involved (like the X11 7.0 upgrade). Other just require (or strongly suggest) another special tool be run (gcc-config, fix_libtool_files.sh, and I seem to recall others) too. Most of these that require more tend to be 'key' to safe/proper maintenance of the system. I'd like to see an option where certain packages are not upgrade just because they're out of date, but require an additional command line argument. Additionally, a tool that I could run that tells me the following packages are being 'held back' because a more involved upgrade - ideally, it would also provide information on what the required steps are. I'm I crazy? David -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/11/06, David Corbin [EMAIL PROTECTED] wrote: I'd like to see an option where certain packages are not upgrade just because they're out of date, but require an additional command line argument. Additionally, a tool that I could run that tells me the following packages are being 'held back' because a more involved upgrade - ideally, it would also provide information on what the required steps are. I'm I crazy? I don't think so. Your comments are very much in line with mine...trying to make the more involved upgrades less error prone. The one concern I have with taking this out of the standard update process is that we really need to keep up with the currently 'stable' software as a minimum. Updating some things that are simple, but letting other packages fall behind, is just asking for breakage at some point. Some recent postings to -dev regarding current software not building with old gcc versions really point out this fact... So I don't think we need yet another tool here. I would prefer to see our existing tools enhanced with this goal in mind. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Richard Fish wrote: On 7/7/06, Daniel Iliev [EMAIL PROTECTED] wrote: Well, correct me if I'm wrong but it think it's not quite true. I *think* if you have buildpkg in your FEATURES, you will get binary packages in your $PKGDIR with the new, updated versions. But previous versions are not deleted until you do an eclean packages. So yeah, you need to have buildpkg in FEATURES for a while to get a nice set of backup packages, or use quickpkg. -Richard And if you have not cleaned out your distfiles, you can always just specify the version you want to emerge as well. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Rafael Fernández López schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What to do when your smtp server needs authentification ? Curse the damned too simple ELOG interface :) That's why I wrote, that I actually use =custom. I wrote a page on the wiki regarding this: Alexander Skwar -- The mother of the year should be a sterilized woman with two adopted children. -- Paul Ehrlich -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Rafael Fernández López schrieb: What to do when your smtp server needs authentification ? Well, I wrote a page on the wiki. And I wanted to post the URL, but my fingers are too clumsy :) http://gentoo-wiki.com/TIP_Making_portage_use_/usr/sbin/sendmail_to_send_out_ELOG_mails In this wiki TIP, I show how portage can be configured, so that it uses /usr/sbin/sendmail to send out mails. On my system, /usr/sbin/sendmail is SSMTP and I configured SSMTP to use auth. But if you're *only* after being able to auth. yourself to the SMTP server, you don't need my tip. Portage can do this by itself. Just have a look at the description of PORTAGE_ELOG_MAILURI in /etc/make.conf.example. HTH, Alexander Skwar -- My friend has a baby. I'm writing down all the noises he makes so later I can ask him what he meant. -- Steven Wright -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Walter Dnes schrieb: On Fri, Jul 07, 2006 at 09:22:29PM +0200, Rafael Fern??ndez L??pez wrote This is not flame war. I love Gentoo, and it is the distribution that fits me perfectly, but I've been wondering this last year what things can be improved in this wonderful distro. The first thing that I'd change is etc-update or dispatch-conf. etc-update needs only one change to make it perfect for me, namely the ability to protect changes to default parameters. Here are 3 examples from a recent update, where an automaton has no business touching certain lines... /etc/conf.d/bootmisc -WIPE_TMP=yes +WIPE_TMP=no /etc/conf.d/local.start # This is a good place to load any misc programs -# on startup ( use 12 to hide output) -modprobe snd-virmidi index=1 +# on startup (use /dev/null to hide output) + /etc/conf.d/rc @@ -74,7 +89,12 @@ # and restore it on startup. This is useful if you have a lot of # custom device nodes that udev does not handle/know about. -RC_DEVICE_TARBALL=yes +RC_DEVICE_TARBALL=no + When I say yes I mean yes. When I say no I mean no. And I don't mean just until the next update either. I have reasons for my settings; please don't act like Windows and assume that you know better than me. But actually, they do *NOT* pretend to know better! The way it is now, is, that you're asked if you wish to accept those changes And there is no excuse whatsoever for wiping out the custom settings in /etc/conf.d/local.start Would it be possible to have some comment declaration like... #etc-update-protect-begin WIPE_TMP=yes #etc-update-protect-end ...to protect a block of lines against changes, while allowing other lines to be changed? Hm - that might actually be a good idea. While there are certain *parts* in a configuration file that can be updated, there are certain parts, that shouldn't be. BUT: How should that actually work? Suppose you had this etc-upadte-protect-begin and -end block. How should diff see, that changes in such a block are NOT to be considered? I mean, in the original file, there's *no* such block (and I actually wouldn't want such a block to be in default configuration files). Alexander Skwar -- grasshopotomaus: A creature that can leap to tremendous heights... once. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
There you don't have to ask for permission and a simple diff can reveal the changes whenever I want. A simple diff is all that's done right now (well, basically at least; basically etc-update can be seen as a sort of front-end to diff). To throw my two cents in here, I'd like etc-update to use vimdiff, which is another front-end to diff, and much more intuitive to me. However, doing so would probably enrage emacs users, who, presumably, have a front-end to diff from emacs as well; so maybe an option for vimdiff or emacs-diff -- I bet either would be better than the current script. --David -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Dalrymple wrote: There you don't have to ask for permission and a simple diff can reveal the changes whenever I want. A simple diff is all that's done right now (well, basically at least; basically etc-update can be seen as a sort of front-end to diff). To throw my two cents in here, I'd like etc-update to use vimdiff, which is another front-end to diff, and much more intuitive to me. However, doing so would probably enrage emacs users, who, presumably, have a front-end to diff from emacs as well; so maybe an option for vimdiff or emacs-diff -- I bet either would be better than the current script. --David David, - From /etc/etc-update.conf: snip # vim-users: you CAN use vimdiff for diff_command. (see NOTE_1) #diff_command=vim -d %file1 %file2 #using_editor=1 diff_command=colordiff -uN %file1 %file2 using_editor=0 # vim-users: don't use vimdiff for merging (see NOTE_1) merge_command=sdiff -s -o %merged %orig %new /snip You can see here that you *CAN* use vimdiff, I personally use colordiff which you can see above. HTH - -- Jeremy Olexa ([EMAIL PROTECTED]) Office: EE/CS 1-201 CS/IT Systems Staff University of Minnesota -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsSjIFN7pD9kMi/URAmn2AJoCs07KzgLkqiTbb/zmnT1i5iPNFgCfYW9a JZLAHyEhGsvVkeBdss8wK5Q= =/qHY -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sunday 9 July 2006 17:53, David Dalrymple wrote: To throw my two cents in here, I'd like etc-update to use vimdiff, which is another front-end to diff, and much more intuitive to me. I think that vimdiff is the same as vim -d; if this is correct, just edit /etc/etc-update.conf and enable vim -d for your diff_command (it's commented out by default). -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
David Dalrymple schrieb: There you don't have to ask for permission and a simple diff can reveal the changes whenever I want. A simple diff is all that's done right now (well, basically at least; basically etc-update can be seen as a sort of front-end to diff). To throw my two cents in here, I'd like etc-update to use vimdiff, Then configure etc-update to use vimdiff. See /etc/etc-update.conf which is another front-end to diff, and much more intuitive to me. However, doing so would probably enrage emacs users, who, presumably, have a front-end to diff from emacs as well; so maybe an option for vimdiff or emacs-diff -- I bet either would be better than the current script. No, it would NOT be *BETTER*. One of the nice things of the current default setup is, that it is rather basic. Alexander Skwar -- All international orders must be accompanied by payment in U. S. funds. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sun, 09 Jul 2006 17:18:32 +0200, Alexander Skwar wrote: What to do when your smtp server needs authentification ? Curse the damned too simple ELOG interface :) That's why I wrote, that I actually use =custom. I wrote a page on the wiki regarding this: What's wrong with the procedure outlined in /etc/make.conf.example (I haven't tried it)? # PORTAGE_ELOG_MAILURI: this variable holds all important settings for the mail # module. In most cases listing the recipient address and # the receiving mailserver should be sufficient, but you can # also use advanced settings like authentication or TLS. The # full syntax is: # address [[user:[EMAIL PROTECTED]:port]] # where # address:recipient address # user: username for smtp auth (defaults to none) # passwd: password for smtp auth (defaults to none) # mailserver: smtp server that should be used to deliver the mail -- Neil Bothwick signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
Neil Bothwick schrieb: On Sun, 09 Jul 2006 17:18:32 +0200, Alexander Skwar wrote: What to do when your smtp server needs authentification ? Curse the damned too simple ELOG interface :) That's why I wrote, that I actually use =custom. I wrote a page on the wiki regarding this: What's wrong with the procedure outlined in /etc/make.conf.example (I haven't tried it)? Regarding what OP the wants? Nothing. When I wrote the message to which you replied, I hadn't thought about what the OP wanted. My fault. But in my 2nd message, I also suggested to use PORTAGE_ELOG_MAILURI, just like you now did. But there are potential problems which are due to the syntax of the mailuri. What do you do, when the username or password contains an : or @? Especially an @ in the username might not be so strange, as it might happen, that the username is the mailadress, incl. the domain; something like [EMAIL PROTECTED] Would PORTAGE_ELOG_MAILURI=[EMAIL PROTECTED] user:[EMAIL PROTECTED]:pass_with_:[EMAIL PROTECTED]@mailserver:port work? For clarification: user=user:[EMAIL PROTECTED] pass=pass_with_:[EMAIL PROTECTED] mailserver=mailserver port=port Alexander Skwar -- politics, n.: A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage. -- Ambrose Bierce -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sunday 09 July 2006 17:29, Alexander Skwar wrote: As I wrote in an other mail: Stop interfering with the actual configfile and add the changes to a config.conf.dist file. Yep, you wrote that, and I answered that *I* would *NOT* like this. I like it, that I can use a program right away - at least in a default way. If you had your way, *NO* program which relied on configuration files would be usable after installation, as no configuration file could be found. Because of that, I would not want to happen what you proposed. Sure, and it's such a big deal to copy the dist to a non dist on first emerge and update the dist version afterwards. My whole point is that etc-update and friends should stay out of my manually adjusted config files once I've touched them as basicly the only thing etc-update is doing now is proposing to return all the settings to the defaults. Even if there is an new setting or something removed it would get lost in all the other fluff. As for software running on pure and unchecked default configs.. That's, especially for more low level software, not the smartest thing to rely on. Gerhard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Gerhard Hoogterp schrieb: On Sunday 09 July 2006 17:29, Alexander Skwar wrote: As I wrote in an other mail: Stop interfering with the actual configfile and add the changes to a config.conf.dist file. Yep, you wrote that, and I answered that *I* would *NOT* like this. I like it, that I can use a program right away - at least in a default way. If you had your way, *NO* program which relied on configuration files would be usable after installation, as no configuration file could be found. Because of that, I would not want to happen what you proposed. Sure, and it's such a big deal to copy the dist to a non dist on first emerge and update the dist version afterwards. Sure, it's no big deal to make the distribution harder to use. You're right. But you might have a hard time convincing e.g. the gentopia people to do what you propose. My whole point is that etc-update and friends should stay out of my manually adjusted config files once I've touched them Then you've got no point, since etc-update and friends *do* stay out of your files; etc-update even stays out of the configuration files, if *you* haven't modfied them. As for software running on pure and unchecked default configs.. That's, especially for more low level software, Actually, it's not. Not necessarily, at least. not the smartest thing to rely on. Yes, I also think, that you're quite a stupid person. You know, I dislike being called not smart. And I actually find this somewhat of an offense. Alexander Skwar -- We don't need no education, we don't need no thought control. -- Pink Floyd -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sun, 09 Jul 2006 20:18:25 +0200, Alexander Skwar wrote: Would PORTAGE_ELOG_MAILURI=[EMAIL PROTECTED] user:[EMAIL PROTECTED]:pass_with_:[EMAIL PROTECTED]@mailserver:port work? For clarification: user=user:[EMAIL PROTECTED] pass=pass_with_:[EMAIL PROTECTED] mailserver=mailserver port=port I've no idea, and I hope I never need to find out! While ISP logins often use the full email address, the mailserver login is generally just the username. If not, it looks like you're out of luck as portage_mail.py uses the first @ to separate the authentication data from the server. I guess it needs someone with such an address to file a bug report. -- Neil Bothwick Life Support System Failure - Reboot Patient (Y/n)? signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
Rafael Fernández López wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What to do when your smtp server needs authentification ? add sasl support to yout MTA? kashani -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
You can see here that you *CAN* use vimdiff, I personally use colordiff which you can see above. HTH Ah, very nice. So then the alleged problems in etc-update lie not with the frontend to diff itself, but with the idea of using a frontend to diff (as opposed to a more complex system)? --David -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Saturday 08 July 2006 04:23, Zac Medico wrote: Look inside $PORTDIR/sys-apps/portage/files/README.RESCUE and you'll see this: Please see http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml for a recovery guide for a broken portage installation. yeah, but that does not change the fact, that some time (years?) ago, there was a portage-rescue package. Which I even used once ... unpack it and you had a working portage - if you did not have destroyed python ;) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sat, 08 Jul 2006 02:00:27 +0300, Daniel Iliev wrote: 1) I would like to see an implementation of PAUSE. I mean, during most of the emerges there is not only one package to be emerged. Some of the packages have instructions for additional post installation steps that the user should take. Well, I think there should be a FETURE, a flag to emerge or some other mechanism to tell portage to wait for confirmation if the ebuild gives such information. emerge is, by definition, a non-interactive program (apart from --ask which works before emerge starts its business). Use the ELOG features of portage 2.1 to have this messages save to a file, mailed to you or read out with festival. 3) I hate ebuilds that are rewriting variables that I have set. For example I couldn't find a way to compile mplayer with --disable-runtime-cpudetection, EXTRA_ECONF=--disable-runtime-cpudetection emerge --options mplayer This doesn't work with every ebuild, but it does with most of them. many packages overwrite C(XX)FLAGS. They change -O3 to -O2 etc. Gentoo is about choices but why this happens? My opinion is that portage should warn about the too aggressive setting but to let ME chose to change the settings or not. If it is know that the package will fail with -O3, what is the point of letting it through, even if it warns you. However, an einfo message whenever CFLAGS are overridden would be nice. -- Neil Bothwick I can see clearly now, the brain is gone... signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys, There are some things that I forgot to tell ya. I know that lots of you don't know dpkg-reconfigure, well, it will write the /etc/whatever.conf file for you asking you in an interactive way what do you want to do. I'd compare it to some package's ebuild /usr/portage/whatever/whatever-0.0.1.ebuild conf. I would add a mark for packages that can be configured, as there is a mark for UPDATE, NEW, RE-EMERGE, FETCH... I'd add another one like C for ebuilds that admit conf option. As someone said here before, EMERGE is a not interactive tool (if we don't take in count --ask), but in general it is not interactive. And we can assume that anybody stays in front of monitor all the emerge process, so I'd suggest to print information (or warning) messages in a more efficient way, for example: AT THE END OF THE EMERGE PROCESS, not at the end of each package emerge process. I think that PORTAGE_ELOG_CLASSES, PORTAGE_ELOG_SYSTEM and PORTAGE_ELOG_MAILURI is not so necessary if all messages are printed out at the end of the global emerge process. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEr6UAWFfYaTyFH8oRAisJAJ9rzuxt/wKJPAvXoCdU9d4JcCoIkACghuPf xEju9eUjrUPsOG7HMnM7F9A= =cqyw -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Justin R Findlay wrote: ctrl-s, ctrl-q seems to work for me. This means one still has to monitor the output. In my /etc/make.conf I have: PORTAGE_ELOG_CLASSES=info warn error log PORTAGE_ELOG_SYSTEM=mail syslog PORTAGE_ELOG_MAILURI=[EMAIL PROTECTED] Thank you for pointing this out. It is a new stuff for me. I'll investigate the documentation and give it a try. --snip If you tell it to, portage will log every last configure and gcc statement spewed forth on the command line into /var/log/portage/. Yes, I already have about 400MB of logs there. I still wonder when will come the day I'll wipe them out. :) Gentoo generally overwrites C(XX)FLAGS only when they are problematic (unpredictable or cause breakage) for certain platforms/packages. If you have a customized ebuild you can always drop it into your own overlay. Mine is in /usr/local/portage. If you have multiple overlays you can use gensync from the gentoolkit-dev package to sync with them. The truth is there are only a few ebuilds I want to change something in. Up to now in case I want to change something or the packages doesn't compile the normal way, my practice is to use ebuild `equery w package-name` unpack, do my things in the temp dir, compile manually, put a file .compiled and resume the installation. May be I'll start using my own overlay after I collect enough packages. -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Neil Bothwick wrote: On Sat, 08 Jul 2006 02:00:27 +0300, Daniel Iliev wrote: emerge is, by definition, a non-interactive program (apart from --ask which works before emerge starts its business). Use the ELOG features of portage 2.1 to have this messages save to a file, mailed to you or read out with festival. As I already replied to Mr Justin R Findlay's email ELOG is something new to me. I have to check it out. Thank you for pointing this out. EXTRA_ECONF=--disable-runtime-cpudetection emerge --options mplayer This doesn't work with every ebuild, but it does with most of them. Correct. This doesn't work for mplayer. If it is know that the package will fail with -O3, what is the point of letting it through, even if it warns you. However, an einfo message whenever CFLAGS are overridden would be nice. Well, I can't imagine that gentoo maintainers have the opportunity to check all the possible combinations of flags and system setting before they release an ebuild. It is of course better that they prefer to use the safe way. I thing an einfo message is the least thing they could give us, though I prefer to have the choice to try the aggressive setting and if they don't work for me to revert to the recommended flags. -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Rafael Fernández López wrote: Hi guys, There are some things that I forgot to tell ya. I know that lots of you don't know dpkg-reconfigure, well, it will write the /etc/whatever.conf file for you asking you in an interactive way what do you want to do. I'd compare it to some package's ebuild /usr/portage/whatever/whatever-0.0.1.ebuild conf. I would add a mark for packages that can be configured, as there is a mark for UPDATE, NEW, RE-EMERGE, FETCH... I'd add another one like C for ebuilds that admit conf option. As someone said here before, EMERGE is a not interactive tool (if we don't take in count --ask), but in general it is not interactive. And we can assume that anybody stays in front of monitor all the emerge process, so I'd suggest to print information (or warning) messages in a more efficient way, for example: AT THE END OF THE EMERGE PROCESS, not at the end of each package emerge process. I think that PORTAGE_ELOG_CLASSES, PORTAGE_ELOG_SYSTEM and PORTAGE_ELOG_MAILURI is not so necessary if all messages are printed out at the end of the global emerge process. I haven't investigated yet this ELOG thing but I couldn't I agree more than this with you! *CHEERS* -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sat, Jul 08, 2006 at 05:42:25PM +0300, Daniel Iliev wrote: Yes, I already have about 400MB of logs there. I still wonder when will come the day I'll wipe them out. :) I have a simple cron job that bzip2's them and about a year's worth of logs amounts to about 30 Mib, but I should probably rework it to expire old logs. The truth is there are only a few ebuilds I want to change something in. Up to now in case I want to change something or the packages doesn't compile the normal way, my practice is to use ebuild `equery w package-name` unpack, do my things in the temp dir, compile manually, put a file .compiled and resume the installation. May be I'll start using my own overlay after I collect enough packages. I suggest putting your modifications into your own ebuild in an overlay because it may be simpler and neater to apply your changes to the new version/ebuild of the package when it comes out rather than having to remember everything you did the first time manually. Justin -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Rafael Fernández López schrieb: The first thing that I'd change is etc-update or dispatch-conf. I'd suggest to create some kind of tool like dpkg-reconfigure in Debian. More intuitive than reading /etc files and writing them by hand that is more probably to be mistaken when writing. Please do *NOT* do that! I don't want some kind of wizard offering me choices, of which none might fit my needs. Alexander Skwar -- Im Endeffekt war alles cooler als letztes Jahr, obwohl ich bis Donnerstag dachte, das es nicht geht. -- Igor Gilitschenski -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Rafael Fernández López schrieb: Second thing that I'd improve is a security one. I know that emerge is a very cared package, but it is a script. Suppose that someone commits portage with a emerge failure in its code (he forgot a comma !!)... if someone updates portage won't be able to update it again because it will fail ever and ever again... So I suggest to have a backuped emerge script that we are sure that worked (like the last emerge tool that was used), and if the new emerge tool is mistaken (so that user doesn't need to know python) only has to run regenemerge for example, and will have the latest emerge working tool. I disagree with that as well. Changes should only happen in the keyworded packages (ie. ~x86, ...). That's the testing area of Gentoo. If a package breaks in testing: Fine! That's what's testing is for. Alexander Skwar -- Im Endeffekt war alles cooler als letztes Jahr, obwohl ich bis Donnerstag dachte, das es nicht geht. -- Igor Gilitschenski -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Lord Sauron schrieb: On 7/7/06, Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lord Sauron wrote: My personal gripe is how slow emerge is on just plain old emerge-ish things. That we have to use things like eix to search is pathetic. This NEVER happened in Debian. emerge/portage has lots of room for improvement. Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess. However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch. It's getting better, slowly but surely. Yes, it does. However, portage aside, it lacks something like aptitude to really fill in the loose ends. There are so many technical issues that remain to be solved in portage that it's difficult to justify spending time on problems that have already been solved in one way or another. There many tools in existence that already do the search part pretty well. Lots of other things still need fixing... Yeah. Portage works, however, I think it's really in need of a large overhaul. If what you're saying is true, and it's really just a load of scripts, then I really would HIGHLY suggest that you consider beginning to make smaller helper applications in C and stuff to speed things up. What makes you think, that emerge in C would be faster? Would it really be noticeably faster? Scripts are great, but they aren't for whole applications. I disagree. Scripts (interpreted computing languages would be more to the point, though) are great, EVEN for whole applications. Reason: Easier and faster development. Alexander Skwar -- Im Endeffekt war alles cooler als letztes Jahr, obwohl ich bis Donnerstag dachte, das es nicht geht. -- Igor Gilitschenski -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Rafael Fernández López schrieb: I know that lots of you don't know dpkg-reconfigure, well, it will write the /etc/whatever.conf file for you asking you in an interactive way what do you want to do. But etc-update is interactive as well, isn't it? process, so I'd suggest to print information (or warning) messages in a more efficient way, for example: AT THE END OF THE EMERGE PROCESS, not at the end of each package emerge process. I think that PORTAGE_ELOG_CLASSES, PORTAGE_ELOG_SYSTEM and PORTAGE_ELOG_MAILURI is not so necessary if all messages are printed out at the end of the global emerge process. I used to think the same, but changed my mind with the introduction of PORTAGE_ELOG_SYSTEM=mail (or actually, =custom). Reason: This way, I get all the messages mailed to me, for me to review. That's *IMO* even better. Reason: You get the messages earlier and suppose the system crashes in the middle of the emerge. If all the messages were just shown at the end, some messages might be lost. No. With the advent of PORTAGE_ELOG_*, everything is fine as far as I'm concerned. Alexander Skwar -- Im Endeffekt war alles cooler als letztes Jahr, obwohl ich bis Donnerstag dachte, das es nicht geht. -- Igor Gilitschenski -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sat, 08 Jul 2006 20:30:06 +0200, Alexander Skwar wrote: I know that lots of you don't know dpkg-reconfigure, well, it will write the /etc/whatever.conf file for you asking you in an interactive way what do you want to do. But etc-update is interactive as well, isn't it? And you can configure etc-update and dispatch-conf to use whatever you want to applky changes to files, such as vimdiff, kdiff3 or meld. -- Neil Bothwick If you consult enough experts, you can confirm any opinion. signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
On Fri, Jul 07, 2006 at 09:22:29PM +0200, Rafael Fern??ndez L??pez wrote This is not flame war. I love Gentoo, and it is the distribution that fits me perfectly, but I've been wondering this last year what things can be improved in this wonderful distro. The first thing that I'd change is etc-update or dispatch-conf. etc-update needs only one change to make it perfect for me, namely the ability to protect changes to default parameters. Here are 3 examples from a recent update, where an automaton has no business touching certain lines... /etc/conf.d/bootmisc -WIPE_TMP=yes +WIPE_TMP=no /etc/conf.d/local.start # This is a good place to load any misc programs -# on startup ( use 12 to hide output) -modprobe snd-virmidi index=1 +# on startup (use /dev/null to hide output) + /etc/conf.d/rc @@ -74,7 +89,12 @@ # and restore it on startup. This is useful if you have a lot of # custom device nodes that udev does not handle/know about. -RC_DEVICE_TARBALL=yes +RC_DEVICE_TARBALL=no + When I say yes I mean yes. When I say no I mean no. And I don't mean just until the next update either. I have reasons for my settings; please don't act like Windows and assume that you know better than me. And there is no excuse whatsoever for wiping out the custom settings in /etc/conf.d/local.start Would it be possible to have some comment declaration like... #etc-update-protect-begin WIPE_TMP=yes #etc-update-protect-end ...to protect a block of lines against changes, while allowing other lines to be changed? -- Walter Dnes [EMAIL PROTECTED] In linux /sbin/init is Job #1 My musings on technology and security at http://tech_sec.blog.ca -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sat, 8 Jul 2006 22:32:58 +0200, Hemmann, Volker Armin wrote: FEATURES=buildpkg emerge --oneshot portage python I know that. I prefer quickpkg. ;) The difference is that the buildpkg approach verifies the package by building it and then installing from it. Before a big, scary update, I quickpkg gcc, glibc or what else gets updated. Using buildpkg means I never have to worry about forgetting to run quickpkg, i can concentrate on all the other things I forget to do :) -- Neil Bothwick Those who can, do. Those who cannot, teach. Those who cannot teach, HACK! signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
When I say yes I mean yes. When I say no I mean no. And I don't mean just until the next update either. I have reasons for my settings; please don't act like Windows and assume that you know better than me. And there is no excuse whatsoever for wiping out the custom settings in /etc/conf.d/local.start As I wrote in an other mail: Stop interfering with the actual configfile and add the changes to a config.conf.dist file. There you don't have to ask for permission and a simple diff can reveal the changes whenever I want. During install a copy of this file could be installed already for direct use.. Something alike for the messages during an emerge. Often I see instructions on what to do after the emerge flashing by while doing an emerge world, I don't even want to know how many I miss.. Why not log those to a seperate file so one can actually find them back afterwards? I know Gentoo is supposed to be for those who know how to deal with things, but that doesn't mean it should be more complicated of dangerous than needed.. Gerhard -- Ithaka photography, http://funsite.mine.nu -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What to do when your smtp server needs authentification ? Cheers, Rafael Fernández López. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsB2PWFfYaTyFH8oRAj9pAJwIQtBnh4+aKBHYgHeEo+YxoIjBMACfZHWr zbnjGAFVS/F+JqZnR2HPc6E= =i9LC -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Saturday 08 July 2006 23:00, Neil Bothwick wrote: On Sat, 8 Jul 2006 22:32:58 +0200, Hemmann, Volker Armin wrote: FEATURES=buildpkg emerge --oneshot portage python I know that. I prefer quickpkg. ;) The difference is that the buildpkg approach verifies the package by building it and then installing from it. Before a big, scary update, I quickpkg gcc, glibc or what else gets updated. Using buildpkg means I never have to worry about forgetting to run quickpkg, i can concentrate on all the other things I forget to do :) yeah, but some people are a little bit harddisc-space constraint ;) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Daniel Iliev wrote: Neil Bothwick wrote: EXTRA_ECONF=--disable-runtime-cpudetection emerge --options mplayer This doesn't work with every ebuild, but it does with most of them. Correct. This doesn't work for mplayer. [EMAIL PROTECTED] ~ $ equery u mplayer [ Searching for packages matching mplayer... ] [ Colour Code : set unset ] [ Legend: Left column (U) - USE flags from make.conf ] [ : Right column (I) - USE flags packages was installed with ] [ Found these USE variables for media-video/mplayer-1.0_pre8 ] U I snip - - cpudetection : Enables runtime cpudetection snip So, you want USE=-cpudetection for mplayer. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Sat, 8 Jul 2006 23:10:17 +0200, Hemmann, Volker Armin wrote: Using buildpkg means I never have to worry about forgetting to run quickpkg, i can concentrate on all the other things I forget to do :) yeah, but some people are a little bit harddisc-space constraint ;) Yeah, I know. That's why I thought it would be useful to be able to do this on a per-package basis, or just for system packages. -- Neil Bothwick I've been fishing with Salvador Dali, he used a dotted line and caught every other fish. signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
On Sat, 8 Jul 2006 22:59:24 +0200, Gerhard Hoogterp wrote: Something alike for the messages during an emerge. Often I see instructions on what to do after the emerge flashing by while doing an emerge world, I don't even want to know how many I miss.. Why not log those to a seperate file so one can actually find them back afterwards? Have you missed the dozens of references to ELOG already in this thread? -- Neil Bothwick SUBLIMINALsendmoneyTAGLINE signature.asc Description: PGP signature
Re: [gentoo-user] Things that can be improved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rafael Fernández López wrote: Hi, This is not flame war. I love Gentoo, and it is the distribution that fits me perfectly, but I've been wondering this last year what things can be improved in this wonderful distro. The first thing that I'd change is etc-update or dispatch-conf. I'd suggest to create some kind of tool like dpkg-reconfigure in Debian. More intuitive than reading /etc files and writing them by hand that is more probably to be mistaken when writing. I do agree that these tools fall slightly short of the goal - which IMHO it to effectively manage config files when updating packages, and to dumb down the management process. I've noticed that a majority of the *.conf updates (especially recently) tend to be changing the date(s) in the Gentoo copyright notice (from 2005 - 2006) and/or cvs document version header updates (e.g. v1.5 to v1.6). I typically use dispatch-conf, so maybe this is what etc-update calls trivial updates. Without going into too many specifics (since the thread wasn't started in a specific manner), one of my pet peeves about dispatch-conf is that the new, unmodified *.conf files take precedence. I know there's the merge option, and admittedly, I haven't quite figured out how to use that effectively. But if a new *.conf file is presented, shouldn't/couldn't it diff the new with the old and automatically incorporate the differences into the new *.conf file? More to the point, as I'm not familiar with dpkg-reconfigure, or debian for that matter, why not point out specific short-comings of the existing tools? Or propose a better approach to solving the *.conf file management issue (philosophically or technically - i.e. write one)? Second thing that I'd improve is a security one. I know that emerge is a very cared package, but it is a script. Suppose that someone commits portage with a emerge failure in its code (he forgot a comma !!)... if someone updates portage won't be able to update it again because it will fail ever and ever again... So I suggest to have a backuped emerge script that we are sure that worked (like the last emerge tool that was used), and if the new emerge tool is mistaken (so that user doesn't need to know python) only has to run regenemerge for example, and will have the latest emerge working tool. I don't know if this is technically a security issue, moreso an availability issue (which, yes, technically falls under security in terms of confidentiality-integrity-availability, but in my mind falls slightly outside of the umbrella). While you present a valid concern, I believe this is addressed by the whole masking/testing process that is currently architected into portage. If a portage developer managed to leave out a comma when doing a cvs commit, it's *very* likely going to be found before portage is moved to the stable tree. Worst case scenario, if something like this *were* to fall through the cracks, grab your trusty install-CD and revert to a known-good portage snapshot. Between the lists/forums/announcements/wiki/etc., I'm sure that something like this would surface /immediately/. Just my 2¢... -- gentux echo hfouvyyAhnbjm/dpn | perl -pe 's/(.)/chr(ord($1)-1)/ge' gentux's gpg fingerprint == 5495 0388 67FF 0B89 1239 D840 4CF0 39E2 18D3 4A9E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFErsVqTPA54hjTSp4RApBDAKC9nlQd45p1UkwM8nD+WGOh+ZLewwCgrX9q DvV9ZNnD3GQjYEtd4DeCR0w= =sguh -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Rafael Fernández López [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is not flame war. I love Gentoo, and it is the distribution that fits me perfectly, but I've been wondering this last year what things can be improved in this wonderful distro. The first thing that I'd change is etc-update or dispatch-conf. I'd suggest to create some kind of tool like dpkg-reconfigure in Debian. More intuitive than reading /etc files and writing them by hand that is more probably to be mistaken when writing. This has been already discussed in the list, and a good discussion too. There are tools that do the job better/faster for someone's opinnion (not mine, I still like etc-update). You can choose that tools, I don't know Debian, but I doubt a combination of all tools mentioned at that thread would not come close to what you want. Second thing that I'd improve is a security one. I know that emerge is a very cared package, but it is a script. Suppose that someone commits portage with a emerge failure in its code (he forgot a comma !!)... if someone updates portage won't be able to update it again because it will fail ever and ever again... So I suggest to have a backuped emerge script that we are sure that worked (like the last emerge tool that was used), and if the new emerge tool is mistaken (so that user doesn't need to know python) only has to run regenemerge for example, and will have the latest emerge working tool. There are SO MANY ways to recover portage. A snapshot, a binary package. If you run stable, its almost impossible, to say the least, that you're gonna get a trivial error in emerge that prevents it from running, if you run testing, still, gentoo devs are responsable people and would not do something like that. If we count with that kind of error, your regenemerge command would have to redownload and compile python, portagem, pycrypt, gcc, glibc and a lot of other packages that emerge depends on. You can always quickpkg portage once in a while, but any portage snapshot untared at / would recover most of portage for you. No flames intended, I just say there are ways to do all this already... But you still can post a feature request anytime. -- Daniel da Veiga Computer Operator - RS - Brazil -BEGIN GEEK CODE BLOCK- Version: 3.1 GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V- PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++ --END GEEK CODE BLOCK-- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Rafael Fernández López [EMAIL PROTECTED] wrote:
The first thing that I'd change is etc-update or dispatch-conf. I'd
suggest to create some kind of tool like dpkg-reconfigure in Debian.
I don't know anything about dpkg-reconfigure, so I can't really comment on this.
But one thing I really do like about gentoo is that I *can* go modify
configuration files directly, without worrying about some distribution
tool clobbering my changes, or choking on something it wasn't setup to
deal with. This is one of the things that drove me from SuSE. I
would really object to some kind of configuration file configurator
app.
Second thing that I'd improve is a security one. I know that emerge
is a very cared package, but it is a script. Suppose that someone
I think this is a non-issue. Something like this would be found
incredibly quickly by the portage devs working in their overlay, and
they would know how to fix it. In the worst of all possible cases, it
might theoretically make it to the ~arch users, who again, presumably
have enough experience to know how to resurrect their systems without
resorting to a live CD and re-install.
It is far more likely that you could break python (and thus portage)
from a mishandled gcc or glibc update. But there is already a
recovery option available in this case; if you have buildpkg in your
FEATURES, you will already have a backup copy of
portage/python/gcc/glibc/everything else in $PKGDIR. Even if portage
is broken, you can extract those tarballs to get back to a working
configuration. Of course, this assumes that tar and bzip2
work...otherwise you are down to booting from a live CD.
One area I do think could be improved is in the update process.
Currently we have etc-update, revdep-rebuild, fix_libtool_files.sh,
eselect {opengl,gcc,binutils}, python-updater, perl-cleaner, and so
on. Each update requires running one or more of these. But which
ones, when, why, and in what order? I *think* _I_ know the answers to
those questions, but I would bet most users do not. So I think a
little more automation (or at least hand-holding) in portage to deal
with the above would be very useful. Something like:
emerge -DNuv world
several hours later
Updates done.
Hmm, looks like a new version of python was installed. You should run
python-updater to make sure all python modules are rebuilt. Do you
want to do that now?
-Richard
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Richard Fish [EMAIL PROTECTED] wrote:
On 7/7/06, Rafael Fernández López [EMAIL PROTECTED] wrote:
The first thing that I'd change is etc-update or dispatch-conf.
I'd
suggest to create some kind of tool like dpkg-reconfigure in Debian.
I don't know anything about dpkg-reconfigure, so I can't really comment on this.
But one thing I really do like about gentoo is that I *can* go modify
configuration files directly, without worrying about some distribution
tool clobbering my changes, or choking on something it wasn't setup to
deal with. This is one of the things that drove me from SuSE. I
would really object to some kind of configuration file configurator
app.
Second thing that I'd improve is a security one. I know that emerge
is a very cared package, but it is a script. Suppose that someone
I think this is a non-issue. Something like this would be found
incredibly quickly by the portage devs working in their overlay, and
they would know how to fix it. In the worst of all possible cases, it
might theoretically make it to the ~arch users, who again, presumably
have enough experience to know how to resurrect their systems without
resorting to a live CD and re-install.
It is far more likely that you could break python (and thus portage)
from a mishandled gcc or glibc update. But there is already a
recovery option available in this case; if you have buildpkg in your
FEATURES, you will already have a backup copy of
portage/python/gcc/glibc/everything else in $PKGDIR. Even if portage
is broken, you can extract those tarballs to get back to a working
configuration. Of course, this assumes that tar and bzip2
work...otherwise you are down to booting from a live CD.
One area I do think could be improved is in the update process.
Currently we have etc-update, revdep-rebuild, fix_libtool_files.sh,
eselect {opengl,gcc,binutils}, python-updater, perl-cleaner, and so
on. Each update requires running one or more of these. But which
ones, when, why, and in what order? I *think* _I_ know the answers to
those questions, but I would bet most users do not. So I think a
little more automation (or at least hand-holding) in portage to deal
with the above would be very useful. Something like:
emerge -DNuv world
several hours later
Updates done.
Hmm, looks like a new version of python was installed. You should run
python-updater to make sure all python modules are rebuilt. Do you
want to do that now?
That's more likely to be needed. +1
--
Daniel da Veiga
Computer Operator - RS - Brazil
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
--END GEEK CODE BLOCK--
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On Friday 07 July 2006 21:22, Rafael Fernández López wrote: Second thing that I'd improve is a security one. I know that emerge is a very cared package, but it is a script. Suppose that someone commits portage with a emerge failure in its code (he forgot a comma !!)... if someone updates portage won't be able to update it again because it will fail ever and ever again... So I suggest to have a backuped emerge script that we are sure that worked (like the last emerge tool that was used), and if the new emerge tool is mistaken (so that user doesn't need to know python) only has to run regenemerge for example, and will have the latest emerge working tool. once upon a time, there was a portage-rescue seems, that it is gone (why?) but you can still find it here: http://dev.gentoo.org/~carpaski/portage_rescue/ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Le vendredi 07 juillet 2006 à 14:12 -0700, Richard Fish a écrit : Hmm, looks like a new version of python was installed. You should run python-updater to make sure all python modules are rebuilt. Do you want to do that now? The problem with this is that it break for users who put emerge in a cron job. It should first detect if you are in an interactive shell. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Richard Fish wrote: --snip It is far more likely that you could break python (and thus portage) from a mishandled gcc or glibc update. But there is already a recovery option available in this case; if you have buildpkg in your FEATURES, you will already have a backup copy of portage/python/gcc/glibc/everything else in $PKGDIR. Even if portage is broken, you can extract those tarballs to get back to a working configuration. Of course, this assumes that tar and bzip2 work...otherwise you are down to booting from a live CD. --snip Well, correct me if I'm wrong but it think it's not quite true. I *think* if you have buildpkg in your FEATURES, you will get binary packages in your $PKGDIR with the new, updated versions. Those that you have just emerged , not the previous ones which you would like to have backed up. Having the newly compiled packages $PKGDIR can be exported via http server as an alias for example: alias /packages /usr/portage/packages and used as PORTAGE_BINHOST=http://192.168.0.1/packages in /etc/make.conf on a buch of other machines. This way one doesn't compile on every single machine but use the already compiled packages. Very useful if you have many equal (as hardware) machines with the same settings in make.conf. The only way (I'm aware of) to make a semiautomatic backup of an already installed package is to use qpkg qpkg is available in app-portage/gentoolkit On the subject. I would say that I like end use Gentoo for two main reasons: 1) it is a binary distro, which means optimization, customization and speed. 2) gentoo doesn't mess with MY config settings without asking if it should. I would hate if some automated tool is ing MY settings without my knowledge. About the damaged portage issue...well, I agree with others who think it is highly unlikely a damaged version to go out and get available for the users. My wish list 1) I would like to see an implementation of PAUSE. I mean, during most of the emerges there is not only one package to be emerged. Some of the packages have instructions for additional post installation steps that the user should take. Well, I think there should be a FETURE, a flag to emerge or some other mechanism to tell portage to wait for confirmation if the ebuild gives such information. 2) More control over portages verbosity. Most of the time I only need to see the portages messages, not all the compilation stuff. The later is interesting to me only if the compilation fails. 3) I hate ebuilds that are rewriting variables that I have set. For example I couldn't find a way to compile mplayer with --disable-runtime-cpudetection, many packages overwrite C(XX)FLAGS. They change -O3 to -O2 etc. Gentoo is about choices but why this happens? My opinion is that portage should warn about the too aggressive setting but to let ME chose to change the settings or not. -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Daniel Iliev [EMAIL PROTECTED] wrote: Well, correct me if I'm wrong but it think it's not quite true. I *think* if you have buildpkg in your FEATURES, you will get binary packages in your $PKGDIR with the new, updated versions. But previous versions are not deleted until you do an eclean packages. So yeah, you need to have buildpkg in FEATURES for a while to get a nice set of backup packages, or use quickpkg. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Rafael Fernández López [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This is not flame war. I love Gentoo, and it is the distribution that fits me perfectly, but I've been wondering this last year what things can be improved in this wonderful distro. I've got a small list of personal pet peeves as well. However, overall Gentoo is beyond excellent. It also gets the honour of being the Distro I've stuck with the longest. The first thing that I'd change is etc-update or dispatch-conf. I'd suggest to create some kind of tool like dpkg-reconfigure in Debian. More intuitive than reading /etc files and writing them by hand that is more probably to be mistaken when writing. Might want to include parts of dpkg in that tool. No sense in re-inventing the wheel, eh? Second thing that I'd improve is a security one. I know that emerge is a very cared package, but it is a script. Suppose that someone commits portage with a emerge failure in its code (he forgot a comma !!)... if someone updates portage won't be able to update it again because it will fail ever and ever again... So I suggest to have a backuped emerge script that we are sure that worked (like the last emerge tool that was used), and if the new emerge tool is mistaken (so that user doesn't need to know python) only has to run regenemerge for example, and will have the latest emerge working tool. It wouldn't have gotten off of the guy's test box I'd think. My personal gripe is how slow emerge is on just plain old emerge-ish things. That we have to use things like eix to search is pathetic. This NEVER happened in Debian. I also am considering trying to adapt aptitude to Gentoo. I think aptitude is the best thing since... anyways, I love aptitude and want to make it portage-friendly. Just having a command-line package browser like aptitude in Gentoo would be awesome. Now is the time to tell me how incredibly stupid I am for imagining something like that. Otherwise I might just fire up KDevelop, grab a copy of aptitude, and start working. I'm known to do things like that. If I have more ideas I'll tell ya. Same here. -- == GCv3.12 == GCS d-(++) s+: a? C++ UL+ P+ L++ E--- W+(+++) N++ o? K? w--- O? M+ V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+ DI+++ D+ G e* h- !r !y = END GCv3.12 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
Lord Sauron wrote: My personal gripe is how slow emerge is on just plain old emerge-ish things. That we have to use things like eix to search is pathetic. This NEVER happened in Debian. Yeah, emerge should probably start caching this info for faster searches. emerge overall though got a pretty solid speedup in 2.1. I also am considering trying to adapt aptitude to Gentoo. I think aptitude is the best thing since... anyways, I love aptitude and want to make it portage-friendly. Just having a command-line package browser like aptitude in Gentoo would be awesome. Now is the time to tell me how incredibly stupid I am for imagining something like that. Otherwise I might just fire up KDevelop, grab a copy of aptitude, and start working. I'm known to do things like that. Might wanna take a look through the stuff in app-portage/ before you start. I'm a fan of porthole. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Things that can be improved
Richard Fish wrote: On 7/7/06, Daniel Iliev [EMAIL PROTECTED] wrote: Well, correct me if I'm wrong but it think it's not quite true. I *think* if you have buildpkg in your FEATURES, you will get binary packages in your $PKGDIR with the new, updated versions. But previous versions are not deleted until you do an eclean packages. So yeah, you need to have buildpkg in FEATURES for a while to get a nice set of backup packages, or use quickpkg. -Richard Oh! But of cource! Now I see your point. Who made me think $PKGDIR is not already containing packages!? :) *CHEERS* -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lord Sauron wrote: My personal gripe is how slow emerge is on just plain old emerge-ish things. That we have to use things like eix to search is pathetic. This NEVER happened in Debian. emerge/portage has lots of room for improvement. Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess. However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch. It's getting better, slowly but surely. There are so many technical issues that remain to be solved in portage that it's difficult to justify spending time on problems that have already been solved in one way or another. There many tools in existence that already do the search part pretty well. Lots of other things still need fixing... Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFErxZt/ejvha5XGaMRAqdoAKCkhZXGvhjY0T5MQY7srfZPPnbl7QCffDpr wDenFodeIt1WEM+wwfzSo9U= =RITY -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hemmann, Volker Armin wrote: On Friday 07 July 2006 21:22, Rafael Fernández López wrote: Second thing that I'd improve is a security one. I know that emerge is a very cared package, but it is a script. Suppose that someone commits portage with a emerge failure in its code (he forgot a comma !!)... if someone updates portage won't be able to update it again because it will fail ever and ever again... So I suggest to have a backuped emerge script that we are sure that worked (like the last emerge tool that was used), and if the new emerge tool is mistaken (so that user doesn't need to know python) only has to run regenemerge for example, and will have the latest emerge working tool. once upon a time, there was a portage-rescue seems, that it is gone (why?) but you can still find it here: http://dev.gentoo.org/~carpaski/portage_rescue/ Look inside $PORTDIR/sys-apps/portage/files/README.RESCUE and you'll see this: Please see http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml for a recovery guide for a broken portage installation. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFErxcY/ejvha5XGaMRAi8xAJ92qQJwuahjZ3IQzVJdoZ9fh8QZvACcCsDc ml2Uz4PQWYGAOClpZVhDajg= =s4iZ -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Zac Medico [EMAIL PROTECTED] wrote: emerge/portage has lots of room for improvement. Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess. However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch. It's getting better, slowly but surely. /me bowes in reverence to Zac. :-) -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Donnie Berkholz [EMAIL PROTECTED] wrote: Lord Sauron wrote: My personal gripe is how slow emerge is on just plain old emerge-ish things. That we have to use things like eix to search is pathetic. This NEVER happened in Debian. Yeah, emerge should probably start caching this info for faster searches. emerge overall though got a pretty solid speedup in 2.1. I have 2.1 and it does have a slight increase in speed, though nothing compared to debian. I also am considering trying to adapt aptitude to Gentoo. I think aptitude is the best thing since... anyways, I love aptitude and want to make it portage-friendly. Just having a command-line package browser like aptitude in Gentoo would be awesome. Now is the time to tell me how incredibly stupid I am for imagining something like that. Otherwise I might just fire up KDevelop, grab a copy of aptitude, and start working. I'm known to do things like that. Might wanna take a look through the stuff in app-portage/ before you start. I'm a fan of porthole. Kuroo is nice, however, portage still lacks the pure brilliance of aptitude. If you don't know what I'm talking about, get debian (or something debain-based) and screw around with aptitude a bit. The think of how cool it'd be that you could use it over ssh without having to use all the memory for remote desktop. Then notice how fast it is once you get savvy and start to really leverage it. It's a far superior piece of software, and I ended up using it rather than graphical things like Adept, Synaptic, KPackage, and others. It kills both porthole and Kuroo, if that's what you're asking. -- == GCv3.12 == GCS d-(++) s+: a? C++ UL+ P+ L++ E--- W+(+++) N++ o? K? w--- O? M+ V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+ DI+++ D+ G e* h- !r !y = END GCv3.12 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lord Sauron wrote: My personal gripe is how slow emerge is on just plain old emerge-ish things. That we have to use things like eix to search is pathetic. This NEVER happened in Debian. emerge/portage has lots of room for improvement. Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess. However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch. It's getting better, slowly but surely. Yes, it does. However, portage aside, it lacks something like aptitude to really fill in the loose ends. There are so many technical issues that remain to be solved in portage that it's difficult to justify spending time on problems that have already been solved in one way or another. There many tools in existence that already do the search part pretty well. Lots of other things still need fixing... Yeah. Portage works, however, I think it's really in need of a large overhaul. If what you're saying is true, and it's really just a load of scripts, then I really would HIGHLY suggest that you consider beginning to make smaller helper applications in C and stuff to speed things up. Right now it does have one thing that I have to say is better than Debian... once you get used to it: package masking. That is something that is really quite nifty that debian lacks, but I wouldn't say is a killer app. I'll be on Gentoo for one reason only: I'm obcessed with learning more about Linux, no matter how much trouble that means I have to get myself into ; ) Perhaps if I ever become good enough at Linux and programming I'll feel brave enough to try and help with the Portage problem... It's definitely a idea I'm beginning to entertain. I may just start looking through the sources. Who knows? With what limited skill I have I may be able to cook up some of those helper applications to speed things up! Scripts are great, but they aren't for whole applications. Yes, that would be a quotable. -- == GCv3.12 == GCS d-(++) s+: a? C++ UL+ P+ L++ E--- W+(+++) N++ o? K? w--- O? M+ V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+ DI+++ D+ G e* h- !r !y = END GCv3.12 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Lord Sauron [EMAIL PROTECTED] wrote: Scripts are great, but they aren't for whole applications. Yes, that would be a quotable. I think (someone please correct me if I am wrong) that most of portage is actually implemented in python. The actual merge process is shell script, but things like dependency resolution and so forth should be all python. And python is actually pretty quick. Not nearly as fast as C, but easily fast enough for this kind of work. I think you would find the biggest gains would be from using more efficient algorithms and data storage, rather than re-implementing parts in another language. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Richard Fish [EMAIL PROTECTED] wrote: On 7/7/06, Lord Sauron [EMAIL PROTECTED] wrote: Scripts are great, but they aren't for whole applications. Yes, that would be a quotable. I think (someone please correct me if I am wrong) that most of portage is actually implemented in python. The actual merge process is shell script, but things like dependency resolution and so forth should be all python. I don't speak much python. And python is actually pretty quick. Not nearly as fast as C, but easily fast enough for this kind of work. I think you would find the biggest gains would be from using more efficient algorithms and data storage, rather than re-implementing parts in another language. Yeah, you're most likely right. -Richard -- gentoo-user@gentoo.org mailing list -- == GCv3.12 == GCS d-(++) s+: a? C++ UL+ P+ L++ E--- W+(+++) N++ o? K? w--- O? M+ V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+ DI+++ D+ G e* h- !r !y = END GCv3.12 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lord Sauron wrote: On 7/7/06, Zac Medico [EMAIL PROTECTED] wrote: Yeah. Portage works, however, I think it's really in need of a large overhaul. If what you're saying is true, and it's really just a load of scripts, then I really would HIGHLY suggest that you consider beginning to make smaller helper applications in C and stuff to speed things up. Right now it does have one thing that I have to say is better than Debian... once you get used to it: package masking. I understand that users are frustrated by a perceived lack of performance. However, even though portage performance is far from optimal in many cases, I'm quite satisfied with it's performance levels in most of the ways that I use it. Surely there's lots of room for improvement, but it's difficult to justify spending time on some types of performance enhancements when there are already plenty of things that are completely broken and in need of fixing. That is something that is really quite nifty that debian lacks, but I wouldn't say is a killer app. I'll be on Gentoo for one reason only: I'm obcessed with learning more about Linux, no matter how much trouble that means I have to get myself into ; ) Perhaps if I ever become good enough at Linux and programming I'll feel brave enough to try and help with the Portage problem... It's definitely a idea I'm beginning to entertain. I may just start looking through the sources. Who knows? With what limited skill I have I may be able to cook up some of those helper applications to speed things up! Scripts are great, but they aren't for whole applications. Yes, that would be a quotable. Well, I'm not interested in debating whether or not a particular language is suitable for a particular type of application development. If you don't like Python, there is a package manager named Paludis that is implemented in C++ and is compatible with Portage in some ways. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFErzaw/ejvha5XGaMRAhxzAKCdVrvIvKz8xCTGQd750cd02YKzdwCggCaI 2jin+5gAX058AJopmB9hl2o= =Tsna -END PGP SIGNATURE- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Things that can be improved
On 7/7/06, Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lord Sauron wrote: On 7/7/06, Zac Medico [EMAIL PROTECTED] wrote: Yeah. Portage works, however, I think it's really in need of a large overhaul. If what you're saying is true, and it's really just a load of scripts, then I really would HIGHLY suggest that you consider beginning to make smaller helper applications in C and stuff to speed things up. Right now it does have one thing that I have to say is better than Debian... once you get used to it: package masking. I understand that users are frustrated by a perceived lack of performance. However, even though portage performance is far from optimal in many cases, I'm quite satisfied with it's performance levels in most of the ways that I use it. Surely there's lots of room for improvement, but it's difficult to justify spending time on some types of performance enhancements when there are already plenty of things that are completely broken and in need of fixing. Yup. I'm not trying to flame the portage people, just point out that it's not working as well as I know it can. For you it might be fine, however, I'm trying to rough it out on a tiny little IBM X40, which is nitorious for being slow. I'm right now trying to find my way into a dual-core turion, and it's looking like I will be able to, but for now I'm stuck, like it or not. Whether or not you/they fix portage isn't my problem, but it won't be because I didn't say that it couldn't use some work. That is something that is really quite nifty that debian lacks, but I wouldn't say is a killer app. I'll be on Gentoo for one reason only: I'm obcessed with learning more about Linux, no matter how much trouble that means I have to get myself into ; ) Perhaps if I ever become good enough at Linux and programming I'll feel brave enough to try and help with the Portage problem... It's definitely a idea I'm beginning to entertain. I may just start looking through the sources. Who knows? With what limited skill I have I may be able to cook up some of those helper applications to speed things up! Scripts are great, but they aren't for whole applications. Yes, that would be a quotable. Well, I'm not interested in debating whether or not a particular language is suitable for a particular type of application development. If you don't like Python, there is a package manager named Paludis that is implemented in C++ and is compatible with Portage in some ways. It's not unusable bad, and I have nothing *against* Python. I just don't know it as well as I do things like PHP, C, C++, C# (yes, I do have a MSDN Membership) and other things. That's all. I was really referring to things like bash and tcsh. They shouldn't be used for whole applications. -- == GCv3.12 == GCS d-(++) s+: a? C++ UL+ P+ L++ E--- W+(+++) N++ o? K? w--- O? M+ V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+ DI+++ D+ G e* h- !r !y = END GCv3.12 -- gentoo-user@gentoo.org mailing list
