Re: [gentoo-user] emerge --update behavior
On Jan 3, 2012 7:08 PM, Neil Bothwick n...@digimed.co.uk wrote: On Tue, 03 Jan 2012 06:49:45 -0500, Tanstaafl wrote: Neil, is the use of sets fully documented somewhere? I don't recall reading about them in the Handbook, but its been a while since I read it (and don't remember if I ever did cover to cover)... I can't recall where I found the documentation, but you can create a set in /etc/portage/sets/ with one atom per line. Then emerge @setname to install the packages. I find them really useful. For example I have a @base set listing all the packages I want on a new install (tmux, gentoolkit, portage-utils etc) so I can copy it to a new install and emerge @base to make sure I have all the tools I normally use. Now *that's* useful. Thanks for the idea! Rgds,
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 21:00:12 -0500, Michael Orlitzky wrote: It is reasonable to assume that the answer to that question is yes. Any other answer raises the question why did Zac spend so much effort recoding portage just to piss off the odd user?. Hah! Many people here are probably employed in IT, software development, or system administration where the job description can be summed up as unfixing things that weren't broken. AFAIK, Zac is not being paid for developing portage, so making changes to justify his employment are not necessary. -- Neil Bothwick She's always late. Her ancestors arrived on the June flower. signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On 2012-01-02 3:48 PM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 2 Jan 2012 09:29:57 -0800, Mark Knecht wrote: That works for the case where the software is managed by portage, which is likely 99.% of what's on Gentoo systems worldwide. It doesn't work however for the odd case where I write some little program which requires a library (ta-lib in my portage file) and I don't write an ebuild to build it. I've never bothered to learn to do my own ebuilds but at some level it would be a good idea, and I think it would address Mr. Orlitsky's issue about what his users need and why. That's more easily handled with sets. No ebuild writing skills are needed and there's no danger of atoms being accidentally added to the set. This sounds very interesting... Neil, is the use of sets fully documented somewhere? I don't recall reading about them in the Handbook, but its been a while since I read it (and don't remember if I ever did cover to cover)... Thanks!
Re: [gentoo-user] emerge --update behavior
On Tue, 03 Jan 2012 06:49:45 -0500, Tanstaafl wrote: Neil, is the use of sets fully documented somewhere? I don't recall reading about them in the Handbook, but its been a while since I read it (and don't remember if I ever did cover to cover)... I can't recall where I found the documentation, but you can create a set in /etc/portage/sets/ with one atom per line. Then emerge @setname to install the packages. I find them really useful. For example I have a @base set listing all the packages I want on a new install (tmux, gentoolkit, portage-utils etc) so I can copy it to a new install and emerge @base to make sure I have all the tools I normally use. -- Neil Bothwick The word 'Windows' is a word out of an old dialect of the Apaches. It means: 'White man staring through glass-screen onto an hourglass...') signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Tuesday 03 Jan 2012 02:00:48 Michael Orlitzky wrote: On 01/02/2012 07:22 PM, Dale wrote: I always knew I was odd. Looks like I have some company tho. Welcome to the odd user group Michael. It ain't us =) Nope. It ain't just you. It's me too. ;-) I'd rather the old default behaviour was retained/returned to. I have to admit even after all this time I will occasionally forget and run emerge -u some_package, only to notice that it was added into world at the end of the emerge. Even worse, it wasn't updated (because no update was available) but was just added in world all the same. Of course when I notice this I go and remove it from world manually and make a mental note not to do this again. When I miss it, the package ends up in world. :-( However, I do wonder how confused could a new user end up being with this (superficially) inconsistent behaviour. The -u option works fine on world (it just updates packages already in world, but not on individual packages (it updates *and* adds said packages in world). I understand the logic, but for the reasons explained by Michael and Dale I also prefer the old behaviour to be the default: nothing gets added in world as a result of updating alone. An enotice message that informs the user that just updating the particular package(s) does not mean they are added to the world file and won't be automatically updated when running 'emerge -u world' in the future, would educate users, along with options for adding the said packages in world. Of course, the opposite will work too; flashing a fat enotice to educate us old dogs to remember to run -1 instead of -u. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] emerge --update behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.01.2012 18:58, Michael Orlitzky wrote: On 01/02/12 12:47, Mark Knecht wrote: Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. This was essentially Michal Mol's suggestion, and I gave an example where it would remove something important. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPAwtEAAoJEJwwOFaNFkYcCIAIAMjC7zIVaGq0ilbfhvWW2lHh X1rsaLGcXIJDEAi6kP69aDyzqP3QSmZFXRid8B2eMLJ+1ZZI/c+VqBLgE8zDU3ai TbamRYeb/kdD2CplanLhDDkQ04DVYhYZXWBJkC7e3IL4assF+2wjiwOsG8Dh0HMh oZ3bbkaR51F5kSSl3xVcWh63B+aU7Zqc3erAjL36mBkoaTOYIYjm7f2uo9vxR2Gv 91d4l5sfrOw7JTtSDMv++6gdrnS8Imh4RrTH3Kd+rUsM2VzzCnnCrWtqTYOhP3JH LFFN55McpjLwHwc0AumG0eQZY+vk7xdS1Ev9bSCd35LwrogluPj5QVhUSwbS//8= =cJtw -END PGP SIGNATURE-
Re: [gentoo-user] emerge --update behavior
On Tue, 03 Jan 2012 15:05:56 +0100 Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de wrote: Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. Sets do exactly the same thing simply without all the added verbiage of an ebuild. The *only* thing required to bring about the solution you describe is the information in the *DEPEND of the meta-ebuild, and that is all that is in a set. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.01.2012 15:47, Alan McKinnon wrote: On Tue, 03 Jan 2012 15:05:56 +0100 Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de wrote: Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. Sets do exactly the same thing simply without all the added verbiage of an ebuild. The *only* thing required to bring about the solution you describe is the information in the *DEPEND of the meta-ebuild, and that is all that is in a set. Then I should try to find some information on sets (custom defined ones). Thank you for the hint! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPAxXjAAoJEJwwOFaNFkYcP64H/0sl77a1uFXW5hL0hM1A5fSN PzKAErLc6inDRzzs0KnsDrFgkDhmPdebga2JG99IGzk+fpS77Cdu6SQUrOvkRwlF 7uzRXXCSCPxOnaHcP6ONVekeOr2HObgc6xPg1fZ8/AK2sbBozjX3N+HTgE0Wl8fW CReSK9kLmseN0YZULD0FvpuvHHs5Rda0VnFl1huY8JJWzUUOxkEkkOcrVCKjLC0I SDO4i5UCtG/pKCUby1/r1m06tR5WuiDm/hQ8/wEMB4C7/a4tZIJ0HcJjtAMYZOvH GIEP2uUIPbhC/rWwnTeM12e0ukWkNVwEnu/dyIhVhV8JOaEJi6ADgKRgimvWJo8= =d+9f -END PGP SIGNATURE-
(Was) Re: [gentoo-user] emerge --update behavior
Hinnerk van Bruinehsen wrote: On 02.01.2012 18:58, Michael Orlitzky wrote: On 01/02/12 12:47, Mark Knecht wrote: Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. This was essentially Michal Mol's suggestion, and I gave an example where it would remove something important. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is complaining that your signature is unverified. I don't know/understand PGP/GPG all that well, but I think this is something you're supposed to be able to fix on your end. If that's not the case, let me know, and I'll get it fixed on my end. :) gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C gpg: Can't check signature: public key not found
Re: (Was) Re: [gentoo-user] emerge --update behavior
Michael Mol wrote: Hinnerk van Bruinehsen wrote: On 02.01.2012 18:58, Michael Orlitzky wrote: On 01/02/12 12:47, Mark Knecht wrote: Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. This was essentially Michal Mol's suggestion, and I gave an example where it would remove something important. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is complaining that your signature is unverified. I don't know/understand PGP/GPG all that well, but I think this is something you're supposed to be able to fix on your end. If that's not the case, let me know, and I'll get it fixed on my end. :) gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C gpg: Can't check signature: public key not found Doh...that was supposed to go directly to Hinnerk. Reply to sender only my hind leg...
Re: (Was) Re: [gentoo-user] emerge --update behavior
On Tuesday 03 Jan 2012 14:55:38 Michael Mol wrote: Michael Mol wrote: Hinnerk van Bruinehsen wrote: On 02.01.2012 18:58, Michael Orlitzky wrote: On 01/02/12 12:47, Mark Knecht wrote: Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. This was essentially Michal Mol's suggestion, and I gave an example where it would remove something important. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is complaining that your signature is unverified. I don't know/understand PGP/GPG all that well, but I think this is something you're supposed to be able to fix on your end. If that's not the case, let me know, and I'll get it fixed on my end. :) gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C gpg: Can't check signature: public key not found Doh...that was supposed to go directly to Hinnerk. Reply to sender only my hind leg... Looks like a recently created gpg key. Assuming the owner has uploaded it to a public key server, it seems likely that it has not propagated across the public servers yet and your enigmail plugin alerts you about it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: (Was) Re: [gentoo-user] emerge --update behavior
Mick wrote: On Tuesday 03 Jan 2012 14:55:38 Michael Mol wrote: Michael Mol wrote: Hinnerk van Bruinehsen wrote: On 02.01.2012 18:58, Michael Orlitzky wrote: On 01/02/12 12:47, Mark Knecht wrote: Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. This was essentially Michal Mol's suggestion, and I gave an example where it would remove something important. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is complaining that your signature is unverified. I don't know/understand PGP/GPG all that well, but I think this is something you're supposed to be able to fix on your end. If that's not the case, let me know, and I'll get it fixed on my end. :) gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C gpg: Can't check signature: public key not found Doh...that was supposed to go directly to Hinnerk. Reply to sender only my hind leg... Looks like a recently created gpg key. Assuming the owner has uploaded it to a public key server, it seems likely that it has not propagated across the public servers yet and your enigmail plugin alerts you about it. Mick, yours gives me the same error: gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6 gpg: Can't check signature: public key not found Though trying querying for 8D16461C or 792968B6 at pool.sks-keyservers.net or subkeys.pgp.net gives me no key found errors.
Re: (Was) Re: [gentoo-user] emerge --update behavior
Mick wrote: On Tuesday 03 Jan 2012 14:55:38 Michael Mol wrote: Michael Mol wrote: Hinnerk van Bruinehsen wrote: On 02.01.2012 18:58, Michael Orlitzky wrote: On 01/02/12 12:47, Mark Knecht wrote: Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. This was essentially Michal Mol's suggestion, and I gave an example where it would remove something important. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now. You could create your own overlay with meta-ebuilds, e. g. system-maintenance, customer1, customer2. Inside the ebuilds you define depends on the packages the customer wants. Doing so you could wipe everything except the meta-ebuilds from world. When a customer quits you can unmerge his or her meta-ebuild and depclean. If you add everything needed to the respective meta-ebuild, you'll always be on the safe side. Getting EnigMail set up on a Seamonkey/Win7 box, and Enigmail is complaining that your signature is unverified. I don't know/understand PGP/GPG all that well, but I think this is something you're supposed to be able to fix on your end. If that's not the case, let me know, and I'll get it fixed on my end. :) gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 09:05:56 using RSA key ID 8D16461C gpg: Can't check signature: public key not found Doh...that was supposed to go directly to Hinnerk. Reply to sender only my hind leg... Looks like a recently created gpg key. Assuming the owner has uploaded it to a public key server, it seems likely that it has not propagated across the public servers yet and your enigmail plugin alerts you about it. Found most of the problem; Enigmail defaulted to an empty automatically download keys for signature vereification from the following keyserver field. Fixed that, and things started working a little better. (Herr Van Bruinehsen's key doesn't seem to have propagated, yes, but now yours works fine. :) )
Re: (Was) Re: [gentoo-user] emerge --update behavior
On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote: Mick, yours gives me the same error: gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6 gpg: Can't check signature: public key not found Though trying querying for 8D16461C or 792968B6 at pool.sks-keyservers.net or subkeys.pgp.net gives me no key found errors. Ahh ... that's probably different then, because my public key has been knocking around for a while. $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys michaelkintz...@gmail.com gpg: enabled debug flags: memstat gpg: searching for michaelkintz...@gmail.com from hkp server keys.gnupg.net (1) Michael Kintzios (Mick) michaelkintz...@gmail.com 1024 bit DSA key 792968B6, created: 2009-04-25 ... [snip] While Hinnerk's key is not found: $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys h.v.bruineh...@fu-berlin.de gpg: enabled debug flags: memstat gpg: searching for h.v.bruineh...@fu-berlin.de from hkp server keys.gnupg.net gpg: key h.v.bruineh...@fu-berlin.de not found on keyserver Have you specified a keyserver to be used as a default in your setup? I use hkp://keys.gnupg.net which operates a round robin function on each connection so as to not over-burden individual servers. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: (Was) Re: [gentoo-user] emerge --update behavior
Mick wrote: On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote: Mick, yours gives me the same error: gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6 gpg: Can't check signature: public key not found Though trying querying for 8D16461C or 792968B6 at pool.sks-keyservers.net or subkeys.pgp.net gives me no key found errors. Ahh ... that's probably different then, because my public key has been knocking around for a while. $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys michaelkintz...@gmail.com gpg: enabled debug flags: memstat gpg: searching for michaelkintz...@gmail.com from hkp server keys.gnupg.net (1) Michael Kintzios (Mick) michaelkintz...@gmail.com 1024 bit DSA key 792968B6, created: 2009-04-25 ... [snip] While Hinnerk's key is not found: $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys h.v.bruineh...@fu-berlin.de gpg: enabled debug flags: memstat gpg: searching for h.v.bruineh...@fu-berlin.de from hkp server keys.gnupg.net gpg: key h.v.bruineh...@fu-berlin.de not found on keyserver Have you specified a keyserver to be used as a default in your setup? I use hkp://keys.gnupg.net which operates a round robin function on each connection so as to not over-burden individual servers. As noted, got it working. Using pool.sks-keyservers.net. Thanks. :)
Re: (Was) Re: [gentoo-user] emerge --update behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.01.2012 18:39, Mick wrote: On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote: Mick, yours gives me the same error: gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6 gpg: Can't check signature: public key not found Though trying querying for 8D16461C or 792968B6 at pool.sks-keyservers.net or subkeys.pgp.net gives me no key found errors. Ahh ... that's probably different then, because my public key has been knocking around for a while. $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys michaelkintz...@gmail.com gpg: enabled debug flags: memstat gpg: searching for michaelkintz...@gmail.com from hkp server keys.gnupg.net (1)Michael Kintzios (Mick) michaelkintz...@gmail.com 1024 bit DSA key 792968B6, created: 2009-04-25 ... [snip] While Hinnerk's key is not found: $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys h.v.bruineh...@fu-berlin.de gpg: enabled debug flags: memstat gpg: searching for h.v.bruineh...@fu-berlin.de from hkp server keys.gnupg.net gpg: key h.v.bruineh...@fu-berlin.de not found on keyserver Have you specified a keyserver to be used as a default in your setup? I use hkp://keys.gnupg.net which operates a round robin function on each connection so as to not over-burden individual servers. It seems like the 'Upload key' function of my enigmail doesn't work. I uploaded the key manually and now I can find it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPA0BTAAoJEJwwOFaNFkYcTkwH/1aClDV0qLS3zWF2qs9BjVXn SZGaYsWv1aM1zranLjS4s2st6bACuKct3twN1B2s/h3m6kRxjGaXVzowvHqsv/yu Py/5HBvBV5X45kflyLG/cJA+Ti9uMMdH5D3J7sm6nRr2mFW1+jbulBJZ2W9W1HMg w2QbMYsDwTkw8xLwlk0/2j3x6rKVwD9oLkYhQEuif51aj1OoWuu8pyCyp0WFUkzl cLizruB/a1UfAU9H+Hv1sdBshY3uJ7dORvzdvfKautsW/WEXjHwqLHvcyOIQ2blN AMwiUj1VMm4jlP1BUzU3OBt6YQDO/LXMppRTv70eibMMScVgmFUUjGC3X5m4H1Y= =c4Iq -END PGP SIGNATURE-
Re: (Was) Re: [gentoo-user] emerge --update behavior
On Tuesday 03 Jan 2012 17:52:19 Hinnerk van Bruinehsen wrote: On 03.01.2012 18:39, Mick wrote: On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote: Mick, yours gives me the same error: gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6 gpg: Can't check signature: public key not found Though trying querying for 8D16461C or 792968B6 at pool.sks-keyservers.net or subkeys.pgp.net gives me no key found errors. Ahh ... that's probably different then, because my public key has been knocking around for a while. $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys michaelkintz...@gmail.com gpg: enabled debug flags: memstat gpg: searching for michaelkintz...@gmail.com from hkp server keys.gnupg.net (1) Michael Kintzios (Mick) michaelkintz...@gmail.com 1024 bit DSA key 792968B6, created: 2009-04-25 ... [snip] While Hinnerk's key is not found: $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys h.v.bruineh...@fu-berlin.de gpg: enabled debug flags: memstat gpg: searching for h.v.bruineh...@fu-berlin.de from hkp server keys.gnupg.net gpg: key h.v.bruineh...@fu-berlin.de not found on keyserver Have you specified a keyserver to be used as a default in your setup? I use hkp://keys.gnupg.net which operates a round robin function on each connection so as to not over-burden individual servers. It seems like the 'Upload key' function of my enigmail doesn't work. I uploaded the key manually and now I can find it. Kewl, now it works fine: $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys h.v.bruineh...@fu-berlin.de gpg: enabled debug flags: memstat gpg: searching for h.v.bruineh...@fu-berlin.de from hkp server keys.gnupg.net (1) Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de 2048 bit RSA key 8D16461C, created: 2011-11-10 Keys 1-1 of 1 for h.v.bruineh...@fu-berlin.de. Enter number(s), N)ext, or Q)uit -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: (Was) Re: [gentoo-user] emerge --update behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mick wrote: On Tuesday 03 Jan 2012 17:52:19 Hinnerk van Bruinehsen wrote: On 03.01.2012 18:39, Mick wrote: On Tuesday 03 Jan 2012 16:18:20 Michael Mol wrote: Mick, yours gives me the same error: gpg command line and output: C:\Program Files (x86)\GNU\GnuPG\gpg.exe gpg: Signature made 01/03/12 11:01:03 using DSA key ID 792968B6 gpg: Can't check signature: public key not found Though trying querying for 8D16461C or 792968B6 at pool.sks-keyservers.net or subkeys.pgp.net gives me no key found errors. Ahh ... that's probably different then, because my public key has been knocking around for a while. $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys michaelkintz...@gmail.com gpg: enabled debug flags: memstat gpg: searching for michaelkintz...@gmail.com from hkp server keys.gnupg.net (1) Michael Kintzios (Mick) michaelkintz...@gmail.com 1024 bit DSA key 792968B6, created: 2009-04-25 ... [snip] While Hinnerk's key is not found: $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys h.v.bruineh...@fu-berlin.de gpg: enabled debug flags: memstat gpg: searching for h.v.bruineh...@fu-berlin.de from hkp server keys.gnupg.net gpg: key h.v.bruineh...@fu-berlin.de not found on keyserver Have you specified a keyserver to be used as a default in your setup? I use hkp://keys.gnupg.net which operates a round robin function on each connection so as to not over-burden individual servers. It seems like the 'Upload key' function of my enigmail doesn't work. I uploaded the key manually and now I can find it. Kewl, now it works fine: $ /usr/bin/gpg2 --keyserver hkp://keys.gnupg.net --search-keys h.v.bruineh...@fu-berlin.de gpg: enabled debug flags: memstat gpg: searching for h.v.bruineh...@fu-berlin.de from hkp server keys.gnupg.net (1)Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de 2048 bit RSA key 8D16461C, created: 2011-11-10 Keys 1-1 of 1 for h.v.bruineh...@fu-berlin.de. Enter number(s), N)ext, or Q)uit ...and testing sending a signed message. Key uploaded manually, but no idea how quickly it will propagate. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPA0c5AAoJEC/SB0LItoL+AnQIAJgoI5bshSkSuqPUOqTgD78t domQfMztoFKNUgzVeQoCPmHgcFYFL8SuhtaARlUXDqPI+fDzbbfY+jGf2fjyAZOc xqqptQVSfxXnuz+usuC3WdcsIHlt4PQjBG+7t8RIArIdE/UIUZlQSfYJTTZVUHBf b4xM7aTCXcoE+FZIoZ0hnAQUyT/+rXBsK4a01tLK7Qt7dmgfhffuOBbHx215WtW3 6Qo9SEjknF8w7v/aLcGw6EI+576R8oRCVoDrF/UFCOx0mKxh4myClQMunmh5y7Zs C4QjlGTEMayIqoJsQQGBWO9DmEdRCxgPtataINb6WBuT7FMq1EQfMtCnPl1fdAo= =oyky -END PGP SIGNATURE-
Re: [gentoo-user] emerge --update behavior
On Tue, Jan 03, 2012 at 09:46:42AM +0200, Alan McKinnon wrote So your actual problem is that you relied on an arbitrary behaviour of portage from the days when the standard was whatever portage does today and you are unhappy because for you that is now broken. But no-one ever promised you that behaviour in a stable API. http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878339 Rule of Least Surprise: In interface design, always do the least surprising thing. (This is also widely known as the Principle of Least Astonishment.) -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] emerge --update behavior
On Sun, 01 Jan 2012 19:24:35 -0500, Michael Orlitzky wrote: Why would you need to take it down? All you need to do is restart Apache after the update. I have to test, like, 200 websites to make sure they still work. Something /always/ breaks. Apache was just an example. PHP is the same way: functions get removed, renamed, or just subtly changed. I can't replace Dovecot with users logged in. I can't upgrade/restart postgresql while clients are hitting it. If I'm working remotely, I don't want to update openvpn, iptables, or even openssh. There's a long list of packages that I just ain't gonna mess with during the day. And you test all this on production servers? -- Neil Bothwick A friend of mine sent me a postcard with a satellite photo of the entire planet on it, and on the back he wrote, Wish you were here. signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Sun, 01 Jan 2012 16:12:34 -0600 Dale rdalek1...@gmail.com wrote: Michael Orlitzky wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. We noticed that a while back too. I added --oneshot to my make.conf setting to prevent this. When you want something added to the world file, check into the --select option. I'm pretty sure that is the one. I do agree that updates shouldn't add things to the world file but I wouldn't hold my breath on it getting changed. The current behaviour is the correct and expected one - you told portage to emerge something and it did. Why else would you emerge something if you didn't intend it to become a permanent feature of the system and part of world? This has always been the definition of emerge - to make it permanent. If you want to emerge something and NOT have portage put it in world then you must use the -1 option. Remember that emerging something is supposed to be a permanent action that you (as root) intended to happen. If what you intend is something more unusual like a mere test or just to see what would happen then you must take additional steps (to make it clear that you are doing something out of the ordinary). It's the same logic as rm uses: the user told the computer to delete a file so the computer did what it was told by it's master and deleted the file. What else would you expect it to do? p.s. before I forget: Happy New Year :-) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On Sun, 01 Jan 2012 19:24:35 -0500 Michael Orlitzky mich...@orlitzky.com wrote: On 01/01/2012 07:09 PM, Neil Bothwick wrote: On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote: Usually it's because a world update wants to do both trivial version bumps and replace major software at the same time. I can't take a server down for an hour in the middle of the day to update Apache, but I can bump timezone-data, sure. Why would you need to take it down? All you need to do is restart Apache after the update. I have to test, like, 200 websites to make sure they still work. Something /always/ breaks. Apache was just an example. PHP is the same way: functions get removed, renamed, or just subtly changed. I can't replace Dovecot with users logged in. I can't upgrade/restart postgresql while clients are hitting it. If I'm working remotely, I don't want to update openvpn, iptables, or even openssh. There's a long list of packages that I just ain't gonna mess with during the day. You have a production machine delivering valuable services to multiple users. Therefore you must only update *anything* on it during planned maintenance slots. If paying customers are involved then preferably with a second redundant parallel machine to take over the load during that slot. You don't have much of an option about this in the real world, think of it as a constraint that you must simply deal with. Or think about it another way, if the machine was running RHEL, you wouldn't just blindly run yum update in the middle of the working day and expect it to all be just fine. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On Monday 02 Jan 2012 10:06:39 Alan McKinnon wrote: On Sun, 01 Jan 2012 19:24:35 -0500 Michael Orlitzky mich...@orlitzky.com wrote: On 01/01/2012 07:09 PM, Neil Bothwick wrote: On Sun, 01 Jan 2012 18:07:45 -0500, Michael Orlitzky wrote: Usually it's because a world update wants to do both trivial version bumps and replace major software at the same time. I can't take a server down for an hour in the middle of the day to update Apache, but I can bump timezone-data, sure. Why would you need to take it down? All you need to do is restart Apache after the update. I have to test, like, 200 websites to make sure they still work. Something /always/ breaks. Apache was just an example. PHP is the same way: functions get removed, renamed, or just subtly changed. I can't replace Dovecot with users logged in. I can't upgrade/restart postgresql while clients are hitting it. If I'm working remotely, I don't want to update openvpn, iptables, or even openssh. There's a long list of packages that I just ain't gonna mess with during the day. You have a production machine delivering valuable services to multiple users. Therefore you must only update *anything* on it during planned maintenance slots. If paying customers are involved then preferably with a second redundant parallel machine to take over the load during that slot. You don't have much of an option about this in the real world, think of it as a constraint that you must simply deal with. Or think about it another way, if the machine was running RHEL, you wouldn't just blindly run yum update in the middle of the working day and expect it to all be just fine. +1 Even on binary distros I would be apprehensive to update/upgrade a production machine, unless I have run the updates on the test box first. Even so, because I do not have the luxury of identical hardware some times the odd thing may break, but it is a very rare occurrence. With everything running on VMs these days (although not yet my case) this is becoming less of a problem I would think. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] emerge --update behavior
Alan McKinnon wrote: The current behaviour is the correct and expected one - you told portage to emerge something and it did. Why else would you emerge something if you didn't intend it to become a permanent feature of the system and part of world? This has always been the definition of emerge - to make it permanent. If you want to emerge something and NOT have portage put it in world then you must use the -1 option. Remember that emerging something is supposed to be a permanent action that you (as root) intended to happen. If what you intend is something more unusual like a mere test or just to see what would happen then you must take additional steps (to make it clear that you are doing something out of the ordinary). It's the same logic as rm uses: the user told the computer to delete a file so the computer did what it was told by it's master and deleted the file. What else would you expect it to do? p.s. before I forget: Happy New Year :-) I didn't tell it to add it to the world file tho, I just told it to update it hence the option --update. I update things all the time but it doesn't mean I want them added to the world file. If I want to emerge something and have it added to the world file, I leave the -u option out of it, then it should be added because I requested it to be emerged not updated. Example: emerge phonon That means I want it emerged on my system and should be added to the world file. emerge -u phonon That means I want to update/upgrade phonon. I don't want it in my world file, just updated. This is the way it worked before --oneshot came along. It is not the way it is now but it was that way a good while back. Happy New Year to you too. Mine are getting better. I lost my Dad on New Years Day many years ago. It's not the same since. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 04:19:39 -0600 Dale rdalek1...@gmail.com wrote: Alan McKinnon wrote: The current behaviour is the correct and expected one - you told portage to emerge something and it did. Why else would you emerge something if you didn't intend it to become a permanent feature of the system and part of world? This has always been the definition of emerge - to make it permanent. If you want to emerge something and NOT have portage put it in world then you must use the -1 option. Remember that emerging something is supposed to be a permanent action that you (as root) intended to happen. If what you intend is something more unusual like a mere test or just to see what would happen then you must take additional steps (to make it clear that you are doing something out of the ordinary). It's the same logic as rm uses: the user told the computer to delete a file so the computer did what it was told by it's master and deleted the file. What else would you expect it to do? p.s. before I forget: Happy New Year :-) I didn't tell it to add it to the world file tho, I just told it to update it hence the option --update. I update things all the time but it doesn't mean I want them added to the world file. If I want to emerge something and have it added to the world file, I leave the -u option out of it, then it should be added because I requested it to be emerged not updated. Example: emerge phonon That means I want it emerged on my system and should be added to the world file. emerge -u phonon That means I want to update/upgrade phonon. I don't want it in my world file, just updated. This is the way it worked before --oneshot came along. It is not the way it is now but it was that way a good while back. Happy New Year to you too. Mine are getting better. I lost my Dad on New Years Day many years ago. It's not the same since. The current behaviour seems more logical to me. You also seem to have gotten used to the old way and can't see past it :-) When Zac needs to define when something does, he needs to keep the big picture in mind to get consistency. So what's the purpose of emerge? Well, read the DESCRIPTION in the man page: = DESCRIPTION emerge is the definitive command-line interface to the Portage system. It is primarily used for installing packages, and emerge can automatically handle any dependencies that the desired package has. emerge can also update the portage tree, making new and updated packages available. emerge gracefully handles updating installed packages to newer releases as well. It handles both source and binary packages, and it can be used to create binary packages for distribution. = Obviously it must maintain system and the world file to do this. That is the primary function, everything else is secondary. When emerge merges something to the live system, it puts everything listed on the command line into world; everything brought along automagically as a dep does not go into world. Any changes to that purpose must have a very good reason. Emergeing something puts it in world, we have established that. But this thing called an update does not imply that the packages are not to go in world - an update is just an update, not merge this but also do something weird with world. Actually --update makes little sense with just individual packages, if they are not already installed they will be (which is exactly what you get by omitting --update). It does make a lot of sense when used with system, world, and sets though. So it seems to me Zac has removed a peculiar bahaviour and made it much more consistent: When you emerge packages explicitly by name, they go into world always. The only way to do it differently is to use -1 which tells portage to not put them in world. Makes sense to me. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
Alan McKinnon wrote: On Mon, 02 Jan 2012 04:19:39 -0600 Dalerdalek1...@gmail.com wrote: Alan McKinnon wrote: The current behaviour is the correct and expected one - you told portage to emerge something and it did. Why else would you emerge something if you didn't intend it to become a permanent feature of the system and part of world? This has always been the definition of emerge - to make it permanent. If you want to emerge something and NOT have portage put it in world then you must use the -1 option. Remember that emerging something is supposed to be a permanent action that you (as root) intended to happen. If what you intend is something more unusual like a mere test or just to see what would happen then you must take additional steps (to make it clear that you are doing something out of the ordinary). It's the same logic as rm uses: the user told the computer to delete a file so the computer did what it was told by it's master and deleted the file. What else would you expect it to do? p.s. before I forget: Happy New Year :-) I didn't tell it to add it to the world file tho, I just told it to update it hence the option --update. I update things all the time but it doesn't mean I want them added to the world file. If I want to emerge something and have it added to the world file, I leave the -u option out of it, then it should be added because I requested it to be emerged not updated. Example: emerge phonon That means I want it emerged on my system and should be added to the world file. emerge -u phonon That means I want to update/upgrade phonon. I don't want it in my world file, just updated. This is the way it worked before --oneshot came along. It is not the way it is now but it was that way a good while back. Happy New Year to you too. Mine are getting better. I lost my Dad on New Years Day many years ago. It's not the same since. The current behaviour seems more logical to me. You also seem to have gotten used to the old way and can't see past it :-) When Zac needs to define when something does, he needs to keep the big picture in mind to get consistency. So what's the purpose of emerge? Well, read the DESCRIPTION in the man page: = DESCRIPTION emerge is the definitive command-line interface to the Portage system. It is primarily used for installing packages, and emerge can automatically handle any dependencies that the desired package has. emerge can also update the portage tree, making new and updated packages available. emerge gracefully handles updating installed packages to newer releases as well. It handles both source and binary packages, and it can be used to create binary packages for distribution. = Obviously it must maintain system and the world file to do this. That is the primary function, everything else is secondary. When emerge merges something to the live system, it puts everything listed on the command line into world; everything brought along automagically as a dep does not go into world. Any changes to that purpose must have a very good reason. Emergeing something puts it in world, we have established that. But this thing called an update does not imply that the packages are not to go in world - an update is just an update, not merge this but also do something weird with world. Actually --update makes little sense with just individual packages, if they are not already installed they will be (which is exactly what you get by omitting --update). It does make a lot of sense when used with system, world, and sets though. So it seems to me Zac has removed a peculiar bahaviour and made it much more consistent: When you emerge packages explicitly by name, they go into world always. The only way to do it differently is to use -1 which tells portage to not put them in world. Makes sense to me. That's why I fixed the new way to be closer to what I am used to. I added --oneshot to my make.conf. When I really need to add something to world, I just use --select y -nav. To me, that is a lot of extra steps to be consistent. That works if it is already installed. For those reading, leave off the -n if it is a fresh new install of a package. The -n means to not compile it, just add it to world. You see my dracut post? I *think* I got init thingy to work. O_O It took me a couple months but . . . . Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 05:06:32 -0600, Dale wrote: That's why I fixed the new way to be closer to what I am used to. I added --oneshot to my make.conf. When I really need to add something to world, I just use --select y -nav. To me, that is a lot of extra steps to be consistent. You are trying to be consistent with your memory of how things used to work (which is flawed, oneshot has been around a lot longer than you think). Zac is looking for self-consistency. Unfortunately, this is one of those cases where there is no overriding argument in favour of one way or the other, prejudice and inertia play more of a part than logic for most people. -- Neil Bothwick Whats the difference between a magician and a brothel? One has a cunning array of stunts, signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 05:06 AM, Alan McKinnon wrote: You have a production machine delivering valuable services to multiple users. Therefore you must only update *anything* on it during planned maintenance slots. If paying customers are involved then preferably with a second redundant parallel machine to take over the load during that slot. You don't have much of an option about this in the real world, think of it as a constraint that you must simply deal with. In a perfect world, we would do this for all updates. But there's only one of me, and my time is better spent doing other things than, * writing documentation * updating the test machine to match production * doing the update * testing all critical services * pushing the update live * retesting just to update ca-certificates on a database server. We do all of the above for major upgrades, and by now I have a pretty good idea of which upgrades are going to break something. I still wind up using emerge -u on the test machines -- I upgrade all of the minor packages and ensure that things are still working before I do the major one, so if something breaks, I'm not chasing ghosts.
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 08:36 AM, Neil Bothwick wrote: On Mon, 02 Jan 2012 05:06:32 -0600, Dale wrote: That's why I fixed the new way to be closer to what I am used to. I added --oneshot to my make.conf. When I really need to add something to world, I just use --select y -nav. To me, that is a lot of extra steps to be consistent. You are trying to be consistent with your memory of how things used to work (which is flawed, oneshot has been around a lot longer than you think). Zac is looking for self-consistency. Unfortunately, this is one of those cases where there is no overriding argument in favour of one way or the other, prejudice and inertia play more of a part than logic for most people. Sure there is: adding a package to the world file can screw up your system if it's unintentional. *Not* adding the package to world when you do an update is *not* harmful, because, * Nobody would use --update to install a new package * Depclean can show you that you made a mistake
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 08:50:36 -0500, Michael Orlitzky wrote: * Nobody would use --update to install a new package Actually, that's a good reason to use --update on a single package, as it installs a new package, but does not reinstall an existing package, so you can emerge -u a list of packages and only install the new ones. However, you can now do that with -n, which does add to world, so this can also be used as an argument for -u to not touch world. I'm leaning towards the view that I would prefer world to be untouched, but, as I said, there's no compelling argument one way or the other. Maybe you can file a bug report that gets enough votes to persuade Zac to add a configuration option for this, or write the patch yourself. -- Neil Bothwick Do radioactive cats have 18 half-lives? signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
Neil Bothwick wrote: On Mon, 02 Jan 2012 08:50:36 -0500, Michael Orlitzky wrote: * Nobody would use --update to install a new package Actually, that's a good reason to use --update on a single package, as it installs a new package, but does not reinstall an existing package, so you can emerge -u a list of packages and only install the new ones. However, you can now do that with -n, which does add to world, so this can also be used as an argument for -u to not touch world. I'm leaning towards the view that I would prefer world to be untouched, but, as I said, there's no compelling argument one way or the other. Maybe you can file a bug report that gets enough votes to persuade Zac to add a configuration option for this, or write the patch yourself. Personally, I'd *really* prefer not to have package manager semantics switch out from under me.
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 08:50:36 -0500 Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 08:36 AM, Neil Bothwick wrote: On Mon, 02 Jan 2012 05:06:32 -0600, Dale wrote: That's why I fixed the new way to be closer to what I am used to. I added --oneshot to my make.conf. When I really need to add something to world, I just use --select y -nav. To me, that is a lot of extra steps to be consistent. You are trying to be consistent with your memory of how things used to work (which is flawed, oneshot has been around a lot longer than you think). Zac is looking for self-consistency. Unfortunately, this is one of those cases where there is no overriding argument in favour of one way or the other, prejudice and inertia play more of a part than logic for most people. Sure there is: adding a package to the world file can screw up your system if it's unintentional. *Not* adding the package to world when you do an update is *not* harmful, because, * Nobody would use --update to install a new package * Depclean can show you that you made a mistake There's a deeper more fundamental assumption at work here, and it's the targeted userbase. Devs assume Gentoo users use Gentoo because the user wants control and tells the computer what to do. By and large that's how it works (except for catastrophic or unrecoverable errors like unmerging python or portage). So when the user tells portage to emerge (not merge) something it goes in world as obviously that's what the user wanted. Presumably the user knows what they are doing and can deal with both pieces. If the user would rather have software hold his hand, that user is better served by Windows or Ubuntu or any number of user-centric distros, but probably not by Gentoo. This isn't elitist, it's just the way things are. Portage's job is to listen to *you*, not to to tell you what you want. The automation portage provides is just the logical conclusion of what should happen in future after you emerged something. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 10:05 AM, Alan McKinnon wrote: So when the user tells portage to emerge (not merge) something it goes in world as obviously that's what the user wanted. Presumably the user knows what they are doing and can deal with both pieces. If the user would rather have software hold his hand, that user is better served by Windows or Ubuntu or any number of user-centric distros, but probably not by Gentoo. This isn't elitist, it's just the way things are. Portage's job is to listen to *you*, not to to tell you what you want. The automation portage provides is just the logical conclusion of what should happen in future after you emerged something. That unspoken agreement is only beneficial if I have the means by which to tell portage what I want it to do. The problem lies at a higher level: I think I'm telling portage to update a package, but that's not what --update means. It's hard for me to tell portage what I want it to do, so the fact that it assumes I know what I'm doing isn't constructive. I wouldn't call it elitist or blame anyone for the change; the entire premise for my argument is that people make mistakes. But I do think it's bad engineering: 50% of users are going to think it works the wrong way no matter which one you choose, but only one of them screws up your system when you get it wrong.
Re: [gentoo-user] emerge --update behavior
On 2012-01-01 5:13 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/01/2012 05:06 PM, Michael Mol wrote: On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzkymich...@orlitzky.com wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. Pretty sure that's what -1 is for. I'm just getting the hang of it myself. Well, I know what I'm *supposed* to do. My complaint is basically that I sometimes forget to add -1 with -u, and that bad things happen as a result. But why should I have to add -1 along with it? Is there any reason you would ever want -u to add a package to your world file? If not, we can avoid headaches in the future by making it do the sane (not harmful) thing. Uh-oh... I've *never* used -1 unless I'm trying to fix a broken package by recompiling it... I've always just used emerge -vuDN world... Been doing it this way for 7+ years, and never had a problem, so my question is: What 'harmful' thing has been happening on/to my system all these years?
Re: [gentoo-user] emerge --update behavior
On 2012-01-01 6:22 PM, Mark Knecht markkne...@gmail.com wrote: 2) I forget the -1 sometimes when I do an individual package update. However I generally remember to go back and hand edit the world file once a quarter or so and remove anything that isn't a real application, etc. How do you tell which is which?
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 10:31 AM, Tanstaafl wrote: Uh-oh... I've *never* used -1 unless I'm trying to fix a broken package by recompiling it... I've always just used emerge -vuDN world... Been doing it this way for 7+ years, and never had a problem, so my question is: What 'harmful' thing has been happening on/to my system all these years? If you only update world, nothing.
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 10:31 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2012-01-01 5:13 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/01/2012 05:06 PM, Michael Mol wrote: On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzkymich...@orlitzky.com wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. Pretty sure that's what -1 is for. I'm just getting the hang of it myself. Well, I know what I'm *supposed* to do. My complaint is basically that I sometimes forget to add -1 with -u, and that bad things happen as a result. But why should I have to add -1 along with it? Is there any reason you would ever want -u to add a package to your world file? If not, we can avoid headaches in the future by making it do the sane (not harmful) thing. Uh-oh... I've *never* used -1 unless I'm trying to fix a broken package by recompiling it... I've always just used emerge -vuDN world... Been doing it this way for 7+ years, and never had a problem, so my question is: What 'harmful' thing has been happening on/to my system all these years? Probably nothing, because of your use of --deep and --newuse. That's pretty much the way I upgrade software on my system. -- :wq
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 10:35 AM, Tanstaafl wrote: On 2012-01-01 6:22 PM, Mark Knechtmarkkne...@gmail.com wrote: 2) I forget the -1 sometimes when I do an individual package update. However I generally remember to go back and hand edit the world file once a quarter or so and remove anything that isn't a real application, etc. How do you tell which is which? You can't =)
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 10:35 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2012-01-01 6:22 PM, Mark Knecht markkne...@gmail.com wrote: 2) I forget the -1 sometimes when I do an individual package update. However I generally remember to go back and hand edit the world file once a quarter or so and remove anything that isn't a real application, etc. How do you tell which is which? I have 947 packages installed, but only 103 lines in my world file. All of those should be files that I explicitly chose to install at one time or another. If I don't recognize a line or I don't know what it does, out it goes. Then I'll run a pretend depclean, see if anything I *want* is being removed, select those packages, and try the depclean again. Unless you're a developer, you probably don't need most packages under dev-libs/* or media-libs/* in your world file; any that are actually required should be pulled in as a dependency of something else. -- :wq
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 7:35 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2012-01-01 6:22 PM, Mark Knecht markkne...@gmail.com wrote: 2) I forget the -1 sometimes when I do an individual package update. However I generally remember to go back and hand edit the world file once a quarter or so and remove anything that isn't a real application, etc. How do you tell which is which? I tell by knowing which files I want in @world. Everything in world should be a package __I__ specifically want to use. Everything in world (on my machines anyway) is something: 1) I'd call from the command line 2) Need to write a little software myself, most specifically a library 3) Aid in displaying things, like font packages 4) Something required by Gentoo that I don't totally understand, like a virtual package. I just look through every so often and make sure everything seems to meet those sorts of requirements. When I find a library or something else then: 1) I make sure I'm clean with emerge -DuN @world AND emerge -p --depclean 2) I'll delete the questionable item 3) I'll see what happens with the two commands in #1 To me it's pretty straight forward, but I'm also not bothered at all by the idea that emerge package and emerge -u package do the same thing. A machine that doesn't have a package, when updated, should have the package and it should (IMO) be in world, but that's just me. HTH, Mark mark@c2stable ~ $ cat /var/lib/portage/world app-admin/syslog-ng app-benchmarks/bonnie++ app-benchmarks/iozone app-cdr/cdrtools app-cdr/dvd+rw-tools app-editors/vim app-emulation/virtualbox app-emulation/virtualbox-extpack-oracle app-emulation/vmware-player app-forensics/chkrootkit app-misc/screen app-pda/gtkpod app-pda/ifuse app-portage/eix app-portage/gentoolkit app-portage/layman app-portage/portage-utils app-text/acroread dev-util/nvidia-cuda-sdk dev-util/nvidia-cuda-toolkit dev-util/strace dev-vcs/subversion kde-base/kde-meta mail-client/mailx mail-mta/ssmtp media-fonts/font-bitstream-100dpi media-fonts/font-bitstream-75dpi media-fonts/font-bitstream-speedo media-fonts/font-bitstream-type1 media-fonts/freefont-ttf media-fonts/freefonts media-fonts/ttf-bitstream-vera media-gfx/imagemagick media-libs/exiftool media-libs/mesa media-sound/alsa-tools media-sound/alsa-utils media-video/dvdbackup media-video/handbrake media-video/nvidia-settings media-video/smplayer media-video/vobcopy media-video/xine-ui net-analyzer/nettop net-dns/noip-updater net-fs/samba net-im/skype net-misc/ntp net-misc/rdesktop net-misc/telnet-bsd net-misc/tightvnc net-misc/unison net-misc/whois sci-libs/ta-lib sys-apps/dstat sys-apps/hdparm sys-apps/hwinfo sys-apps/less sys-apps/lshw sys-apps/microcode-ctl sys-apps/mlocate sys-apps/portage sys-apps/smartmontools sys-boot/grub-static sys-fs/dosfstools sys-fs/fuse sys-fs/mdadm sys-kernel/gentoo-sources sys-kernel/gentoo-sources:3.1.0-r1 sys-kernel/module-rebuild sys-power/apcupsd sys-power/cpufrequtils sys-power/powertop sys-process/iotop sys-process/lsof sys-process/time sys-process/vixie-cron virtual/jdk virtual/jre www-client/firefox www-plugins/adobe-flash www-servers/thttpd x11-apps/mesa-progs x11-apps/xclock x11-apps/xhost x11-base/xorg-drivers x11-base/xorg-server x11-drivers/nvidia-drivers x11-drivers/xf86-input-evdev x11-drivers/xf86-input-virtualbox x11-drivers/xf86-video-fbdev x11-drivers/xf86-video-virtualbox x11-misc/driconf x11-misc/read-edid x11-misc/xsnap mark@c2stable ~ $
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 11:01 AM, Mark Knecht wrote: I tell by knowing which files I want in @world. Everything in world should be a package __I__ specifically want to use. Everything in world (on my machines anyway) is something: 1) I'd call from the command line 2) Need to write a little software myself, most specifically a library 3) Aid in displaying things, like font packages 4) Something required by Gentoo that I don't totally understand, like a virtual package. I just look through every so often and make sure everything seems to meet those sorts of requirements. When I find a library or something else then: 1) I make sure I'm clean with emerge -DuN @world AND emerge -p --depclean 2) I'll delete the questionable item 3) I'll see what happens with the two commands in #1 To me it's pretty straight forward, but I'm also not bothered at all by the idea that emerge package and emerge -u package do the same thing. A machine that doesn't have a package, when updated, should have the package and it should (IMO) be in world, but that's just me. Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified.
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 11:01 AM, Mark Knecht wrote: I tell by knowing which files I want in @world. Everything in world should be a package __I__ specifically want to use. Everything in world (on my machines anyway) is something: 1) I'd call from the command line 2) Need to write a little software myself, most specifically a library 3) Aid in displaying things, like font packages 4) Something required by Gentoo that I don't totally understand, like a virtual package. I just look through every so often and make sure everything seems to meet those sorts of requirements. When I find a library or something else then: 1) I make sure I'm clean with emerge -DuN @world AND emerge -p --depclean 2) I'll delete the questionable item 3) I'll see what happens with the two commands in #1 To me it's pretty straight forward, but I'm also not bothered at all by the idea that emerge package and emerge -u package do the same thing. A machine that doesn't have a package, when updated, should have the package and it should (IMO) be in world, but that's just me. Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Make a backup copy of your world file. 1a. Remove those four lines. 2a. emerge -p --depclean 3a. Did any of those show up in the to-be-removed set? Add them back. Alternately: 1b. emerge -pev --tree --with-bdeps=y @world 2b Find those packages in the output. The tree form of the display will help you see if anything is depending on them. 3b. If anything is depending on them, you should be able to safely remove them from your world file. I'd follow up with the 1a, 2a, 3a solution to be sure. -- :wq
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 11:16 AM, Michael Mol mike...@gmail.com wrote: On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 11:01 AM, Mark Knecht wrote: I tell by knowing which files I want in @world. Everything in world should be a package __I__ specifically want to use. Everything in world (on my machines anyway) is something: 1) I'd call from the command line 2) Need to write a little software myself, most specifically a library 3) Aid in displaying things, like font packages 4) Something required by Gentoo that I don't totally understand, like a virtual package. I just look through every so often and make sure everything seems to meet those sorts of requirements. When I find a library or something else then: 1) I make sure I'm clean with emerge -DuN @world AND emerge -p --depclean 2) I'll delete the questionable item 3) I'll see what happens with the two commands in #1 To me it's pretty straight forward, but I'm also not bothered at all by the idea that emerge package and emerge -u package do the same thing. A machine that doesn't have a package, when updated, should have the package and it should (IMO) be in world, but that's just me. Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Make a backup copy of your world file. 1a. Remove those four lines. 2a. emerge -p --depclean 3a. Did any of those show up in the to-be-removed set? Add them back. Alternately: 1b. emerge -pev --tree --with-bdeps=y @world 2b Find those packages in the output. The tree form of the display will help you see if anything is depending on them. 3b. If anything is depending on them, you should be able to safely remove them from your world file. I'd follow up with the 1a, 2a, 3a solution to be sure. It just occurred to me...in the future, you might be able to build ebuilds for managing customer requests, to ensure that dependencies on particular packages with USE flags and version requirements are met. I haven't built ebuilds myself yet, but it's on my TODO list. -- :wq
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 8:09 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 11:01 AM, Mark Knecht wrote: I tell by knowing which files I want in @world. Everything in world should be a package __I__ specifically want to use. Everything in world (on my machines anyway) is something: 1) I'd call from the command line 2) Need to write a little software myself, most specifically a library 3) Aid in displaying things, like font packages 4) Something required by Gentoo that I don't totally understand, like a virtual package. I just look through every so often and make sure everything seems to meet those sorts of requirements. When I find a library or something else then: 1) I make sure I'm clean with emerge -DuN @world AND emerge -p --depclean 2) I'll delete the questionable item 3) I'll see what happens with the two commands in #1 To me it's pretty straight forward, but I'm also not bothered at all by the idea that emerge package and emerge -u package do the same thing. A machine that doesn't have a package, when updated, should have the package and it should (IMO) be in world, but that's just me. Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. I'm not clear. You allow your server customers to modify your servers, or what, they asked you to install stuff and now you don't know which of them was needed and why? I'm just not clear. My basic response, again allowing that I don't run servers that have 'customers' on them, is that 'equery depends' is the basic path to determine if any of these are dependencies of other things in the world file. If they are then they themselves possibly don't need to be in the world file unless they meet my rule #2 as they are required for some sort of development work your customer does. I completely agree about travel time. My family lives 350 miles away. I've managed their machines for 10 years this way and only once had a problem that required me to get physical access. In the normal worst case I have a Live CD with a couple of instructions they can execute to get me back into the machine. - Mark
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 02, 2012 at 10:26:02AM -0500, Michael Orlitzky wrote: On 01/02/2012 10:05 AM, Alan McKinnon wrote: So when the user tells portage to emerge (not merge) something it goes in world as obviously that's what the user wanted. Presumably the user knows what they are doing and can deal with both pieces. If the user would rather have software hold his hand, that user is better served by Windows or Ubuntu or any number of user-centric distros, but probably not by Gentoo. This isn't elitist, it's just the way things are. Portage's job is to listen to *you*, not to to tell you what you want. The automation portage provides is just the logical conclusion of what should happen in future after you emerged something. That unspoken agreement is only beneficial if I have the means by which to tell portage what I want it to do. The problem lies at a higher level: I think I'm telling portage to update a package, but that's not what --update means. It's hard for me to tell portage what I want it to do, so the fact that it assumes I know what I'm doing isn't constructive. Look at it this way: with emerge package you tell portage to install a package and add it to world. Period. The package will be installed, no matter whether it’s at the newest version or not. With -u, however, you tell emerge to only do the installation if the package is actually upgradable. So it’s not an action (“upgrade this package”), but an option (“install only if upgradable”). -- Gruß | Greetings | Qapla' I forbid any use of my email addresses with Facebook services. The bad thing about Wikipedia jokes is - Deleted due to lack of relevance. - pgpaq0yGXtOI5.pgp Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 11:22 AM, Mark Knecht wrote: I'm not clear. You allow your server customers to modify your servers, or what, they asked you to install stuff and now you don't know which of them was needed and why? I'm just not clear. They ask us to install stuff, and now we don't know which ones are needed. My basic response, again allowing that I don't run servers that have 'customers' on them, is that 'equery depends' is the basic path to determine if any of these are dependencies of other things in the world file. If they are then they themselves possibly don't need to be in the world file unless they meet my rule #2 as they are required for some sort of development work your customer does. I completely agree about travel time. My family lives 350 miles away. I've managed their machines for 10 years this way and only once had a problem that required me to get physical access. In the normal worst case I have a Live CD with a couple of instructions they can execute to get me back into the machine. Well, travel time sucks too, but I was referring to time travel via e.g. a time machine, in case some wise guy tried to answer well you shouldn't have done that. =)
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 11:16 AM, Michael Mol wrote: Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Make a backup copy of your world file. 1a. Remove those four lines. 2a. emerge -p --depclean 3a. Did any of those show up in the to-be-removed set? Add them back. Alternately: 1b. emerge -pev --tree --with-bdeps=y @world 2b Find those packages in the output. The tree form of the display will help you see if anything is depending on them. 3b. If anything is depending on them, you should be able to safely remove them from your world file. I'd follow up with the 1a, 2a, 3a solution to be sure. Sorry, but these won't work. Let's say that dev-php/PEAR-Mail_Mime has a dependency on dev-php/PEAR-Mail, but I have a customer who needs dev-php/PEAR-Mail for a contact form. Following your process, I would remove dev-php/PEAR-Mail from my world file. If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove PEAR-Mail and break the guy's site.
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 11:25 AM, Frank Steinmetzger wrote: Look at it this way: with emergepackage you tell portage to install a package and add it to world. Period. The package will be installed, no matter whether it’s at the newest version or not. With -u, however, you tell emerge to only do the installation if the package is actually upgradable. So it’s not an action (“upgrade this package”), but an option (“install only if upgradable”). I have no problem seeing it that way, and don't have a semantic preference for one or the other. My problem is that the current behavior can screw up your world file, whereas the old behavior could not.
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 10:35:46 -0500, Tanstaafl wrote: 2) I forget the -1 sometimes when I do an individual package update. However I generally remember to go back and hand edit the world file once a quarter or so and remove anything that isn't a real application, etc. How do you tell which is which? By running --depclean -p afterwards. If it wants to remove something you need, add it to world with emerge -n. -- Neil Bothwick WinErr 00E: Window open - Do not look inside signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 11:33:31 -0500, Michael Orlitzky wrote: Well, travel time sucks too, but I was referring to time travel via e.g. a time machine, in case some wise guy tried to answer well you shouldn't have done that. =) Ah, you mean backups, not time travel :) -- Neil Bothwick Mmmm, trouble with grammer have I, yes? - Yoda signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 11:09:06 -0500, Michael Orlitzky wrote: Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? I use sets to deal with this, so much simpler to organise than a single world file. If I am installing something from outside of portage and it has dependencies, I create a set listing those dependencies and emerge that set. If I remove the package I can remove the set and depclean will unmerge anything not needed by other packages. For example, I use a perl script called zenus (specific to my ISP) and /etc/portage/sets/zenus-deps contains dev-perl/SOAP-Lite perl-gcpan/SOAP-DateTime dev-perl/Class-Inspector dev-perl/Data-Dumper-Concise Those packages may or may not be needed by anything else, but a set means I keep them installed without cluttering world. I do similar for specific projects, especially short term ones so I can clean up after. -- Neil Bothwick Committee (noun): A group of people spending hours taking minutes signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 11:33 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 11:16 AM, Michael Mol wrote: Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Make a backup copy of your world file. 1a. Remove those four lines. 2a. emerge -p --depclean 3a. Did any of those show up in the to-be-removed set? Add them back. Alternately: 1b. emerge -pev --tree --with-bdeps=y @world 2b Find those packages in the output. The tree form of the display will help you see if anything is depending on them. 3b. If anything is depending on them, you should be able to safely remove them from your world file. I'd follow up with the 1a, 2a, 3a solution to be sure. Sorry, but these won't work. Let's say that dev-php/PEAR-Mail_Mime has a dependency on dev-php/PEAR-Mail, but I have a customer who needs dev-php/PEAR-Mail for a contact form. Following your process, I would remove dev-php/PEAR-Mail from my world file. If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove PEAR-Mail and break the guy's site. That's the purpose of the emerge -p step. Presumably, you would see that there's a package in the list that you're not comfortable with removing, you'd decide you didn't want it removed, and you'd add it back to your world set. If you're not comfortable removing *any* package that's in your world set, then, no, there's no way to tell the difference. From this point forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the safest practice for your environment. And start keeping a list of packages installed to meet customers' requests. Portage apparently supports your desired workflow, but it needs to be set up for it. As to recovering from your current scenario...there might be some way to watch your apache processes to identify which files get used over a three-month span, from that list derive a list of which packages were used, and from *that* list, derive a list of which packages weren't used. (Or make an ebuild explicitly identifying the utilized dependencies, and let depclean handle the rest) -- :wq
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 8:57 AM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 02 Jan 2012 10:35:46 -0500, Tanstaafl wrote: 2) I forget the -1 sometimes when I do an individual package update. However I generally remember to go back and hand edit the world file once a quarter or so and remove anything that isn't a real application, etc. How do you tell which is which? By running --depclean -p afterwards. If it wants to remove something you need, add it to world with emerge -n. -- Neil Bothwick That works for the case where the software is managed by portage, which is likely 99.% of what's on Gentoo systems worldwide. It doesn't work however for the odd case where I write some little program which requires a library (ta-lib in my portage file) and I don't write an ebuild to build it. I've never bothered to learn to do my own ebuilds but at some level it would be a good idea, and I think it would address Mr. Orlitsky's issue about what his users need and why. If they are on Gentoo then they could write a simple ebuild that did nothing but install the packages they want. That ebuild goes into world and let's him understand why every package in on the system. In the earlier example if all 4 files were required then this user ebuild has 4 entries in it. They ask him to run it, he runs it, it's in world. End of package issue I think. It doesn't address more system'ish things like editing config file to support those things, etc, but I don't know how that gets done unless he grants sudo to them, etc. Just an idea. Cheers, Mark
Re: [gentoo-user] emerge --update behavior
On 01/02/12 12:06, Michael Mol wrote: That's the purpose of the emerge -p step. Presumably, you would see that there's a package in the list that you're not comfortable with removing, you'd decide you didn't want it removed, and you'd add it back to your world set. Yeah, I'm not sure I can remove any of them. The only way I see to determine what's necessary at this point is to remove it and see if stuff breaks. If you're not comfortable removing *any* package that's in your world set, then, no, there's no way to tell the difference. From this point forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the safest practice for your environment. And start keeping a list of packages installed to meet customers' requests. Portage apparently supports your desired workflow, but it needs to be set up for it. As to recovering from your current scenario...there might be some way to watch your apache processes to identify which files get used over a three-month span, from that list derive a list of which packages were used, and from *that* list, derive a list of which packages weren't used. (Or make an ebuild explicitly identifying the utilized dependencies, and let depclean handle the rest) That's probably more work than copying everything to another box, emptying the world file, and adding things back until stuff works. Either way the current situation is you're kinda screwed which is why I proposed avoiding it in the future (for others, too) by fixing --update.
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 12:39 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/12 12:06, Michael Mol wrote: That's the purpose of the emerge -p step. Presumably, you would see that there's a package in the list that you're not comfortable with removing, you'd decide you didn't want it removed, and you'd add it back to your world set. Yeah, I'm not sure I can remove any of them. The only way I see to determine what's necessary at this point is to remove it and see if stuff breaks. If you're not comfortable removing *any* package that's in your world set, then, no, there's no way to tell the difference. From this point forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the safest practice for your environment. And start keeping a list of packages installed to meet customers' requests. Portage apparently supports your desired workflow, but it needs to be set up for it. As to recovering from your current scenario...there might be some way to watch your apache processes to identify which files get used over a three-month span, from that list derive a list of which packages were used, and from *that* list, derive a list of which packages weren't used. (Or make an ebuild explicitly identifying the utilized dependencies, and let depclean handle the rest) That's probably more work than copying everything to another box, emptying the world file, and adding things back until stuff works. Either way the current situation is you're kinda screwed which is why I proposed avoiding it in the future (for others, too) by fixing --update. I hope you don't take this as a kind of disrespect, but this really feels more like administrator error than tool error. As someone else remarked, it's portage's job to do what you tell it to do; you point the gun, pull the trigger, it delivers the projectile. The biggest bug I can see in this whole mess is that the man page might stand some editing for clarity. -- :wq
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 9:39 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/12 12:06, Michael Mol wrote: That's the purpose of the emerge -p step. Presumably, you would see that there's a package in the list that you're not comfortable with removing, you'd decide you didn't want it removed, and you'd add it back to your world set. Yeah, I'm not sure I can remove any of them. The only way I see to determine what's necessary at this point is to remove it and see if stuff breaks. Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. If you're not comfortable removing *any* package that's in your world set, then, no, there's no way to tell the difference. From this point forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the safest practice for your environment. And start keeping a list of packages installed to meet customers' requests. Portage apparently supports your desired workflow, but it needs to be set up for it. As to recovering from your current scenario...there might be some way to watch your apache processes to identify which files get used over a three-month span, from that list derive a list of which packages were used, and from *that* list, derive a list of which packages weren't used. (Or make an ebuild explicitly identifying the utilized dependencies, and let depclean handle the rest) That's probably more work than copying everything to another box, emptying the world file, and adding things back until stuff works. Either way the current situation is you're kinda screwed which is why I proposed avoiding it in the future (for others, too) by fixing --update. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. - Mark
Re: [gentoo-user] emerge --update behavior
On 01/02/12 12:29, Mark Knecht wrote: That works for the case where the software is managed by portage, which is likely 99.% of what's on Gentoo systems worldwide. It doesn't work however for the odd case where I write some little program which requires a library (ta-lib in my portage file) and I don't write an ebuild to build it. I've never bothered to learn to do my own ebuilds but at some level it would be a good idea, and I think it would address Mr. Orlitsky's issue about what his users need and why. If they are on Gentoo then they could write a simple ebuild that did nothing but install the packages they want. That ebuild goes into world and let's him understand why every package in on the system. In the earlier example if all 4 files were required then this user ebuild has 4 entries in it. They ask him to run it, he runs it, it's in world. End of package issue I think. It doesn't address more system'ish things like editing config file to support those things, etc, but I don't know how that gets done unless he grants sudo to them, etc. I have started writing ebuilds for my own sanity, but it doesn't actually fix the problem. Unless you have perfect discipline and always use --oneshot along with --update, you still don't actually know anything about the packages in your world file! Another example: I have a custom ebuild to install the dependencies for www-apps/movable-type-5.02. One of its dependencies is dev-perl/DBD-mysql. If I have both www-apps/movable-type-5.02 and dev-perl/DBD-mysql in my world file, can I remove the latter? Who knows. Maybe I added it on purpose because I need it, and maybe I forgot --oneshot while updating it. There's no way to tell, and the existence of the ebuild doesn't preclude --oneshot mistakes.
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 12:47 PM, Mark Knecht markkne...@gmail.com wrote: On Mon, Jan 2, 2012 at 9:39 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/12 12:06, Michael Mol wrote: That's the purpose of the emerge -p step. Presumably, you would see that there's a package in the list that you're not comfortable with removing, you'd decide you didn't want it removed, and you'd add it back to your world set. Yeah, I'm not sure I can remove any of them. The only way I see to determine what's necessary at this point is to remove it and see if stuff breaks. Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. The problem is that he won't know which atoms in his current world set are necessarily depended upon by other packages vs the ones which are requested by his customers' request. (Portage knows nothing about his customers' requests; it only knows he installed packages at one point or another.) [snip] -- :wq
Re: [gentoo-user] emerge --update behavior
On 01/02/12 12:45, Michael Mol wrote: I hope you don't take this as a kind of disrespect, but this really feels more like administrator error than tool error. As someone else remarked, it's portage's job to do what you tell it to do; you point the gun, pull the trigger, it delivers the projectile. I don't -- I've admitted this was user error a number of times. Old behavior: user error has no consequences. New behavior: user error permanently breaks your world file.
Re: [gentoo-user] emerge --update behavior
On 01/02/12 12:47, Mark Knecht wrote: Again, 'equery depends' will tell you if any package locatable through the @world hierarchy needs the package. No need to uninstall anything to do that level of investigation. revdep-rebuild -I is also useful, although more historically than now. This was essentially Michal Mol's suggestion, and I gave an example where it would remove something important. Really, the proposal to 'fix --update' doesn't address really knowing what your system is running and why. Get to the root of that and the --update thing becomes the non-issue that many of us think it is. This would be a suggestion to travel back in time and document something that I have no way of knowing now.
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 12:55 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/12 12:45, Michael Mol wrote: I hope you don't take this as a kind of disrespect, but this really feels more like administrator error than tool error. As someone else remarked, it's portage's job to do what you tell it to do; you point the gun, pull the trigger, it delivers the projectile. I don't -- I've admitted this was user error a number of times. Old behavior: user error has no consequences. New behavior: user error permanently breaks your world file. I missed where this was new behavior. Being that this will be the 56th message in this thread, though, I'm not particularly inclined to go back and hunt for it. . -- :wq
Re: [gentoo-user] emerge --update behavior
Tanstaafl tansta...@libertytrek.org writes: On 2012-01-01 6:22 PM, Mark Knecht markkne...@gmail.com wrote: 2) I forget the -1 sometimes when I do an individual package update. However I generally remember to go back and hand edit the world file once a quarter or so and remove anything that isn't a real application, etc. How do you tell which is which? There is a package app-portage/udep which used to do this. However it is masked and marked as not working with current portage facilities (such as EAPI), so is almost certainly not safe to use. It would be good if this could be updated to handle current portage.
Re: [gentoo-user] emerge --update behavior
On 01/02/12 13:07, Michael Mol wrote: On Mon, Jan 2, 2012 at 12:55 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/12 12:45, Michael Mol wrote: I hope you don't take this as a kind of disrespect, but this really feels more like administrator error than tool error. As someone else remarked, it's portage's job to do what you tell it to do; you point the gun, pull the trigger, it delivers the projectile. I don't -- I've admitted this was user error a number of times. Old behavior: user error has no consequences. New behavior: user error permanently breaks your world file. I missed where this was new behavior. Being that this will be the 56th message in this thread, though, I'm not particularly inclined to go back and hunt for it. . It used to work the way I want it to, for years. That's partly why I can't remember to add --oneshot to emerge -uN.
Re: [gentoo-user] emerge --update behavior
Michael Orlitzky wrote: On 01/02/2012 11:25 AM, Frank Steinmetzger wrote: Look at it this way: with emergepackage you tell portage to install a package and add it to world. Period. The package will be installed, no matter whether it’s at the newest version or not. With -u, however, you tell emerge to only do the installation if the package is actually upgradable. So it’s not an action (“upgrade this package”), but an option (“install only if upgradable”). I have no problem seeing it that way, and don't have a semantic preference for one or the other. My problem is that the current behavior can screw up your world file, whereas the old behavior could not. Plus the only way to fix this is to override it in make.conf with the --oneshot option. To me, when you have to fix something like this, something is not done right. I like the way Frank explained this. That was my point way back. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] emerge --update behavior
On Mon, 2 Jan 2012 09:29:57 -0800, Mark Knecht wrote: That works for the case where the software is managed by portage, which is likely 99.% of what's on Gentoo systems worldwide. It doesn't work however for the odd case where I write some little program which requires a library (ta-lib in my portage file) and I don't write an ebuild to build it. I've never bothered to learn to do my own ebuilds but at some level it would be a good idea, and I think it would address Mr. Orlitsky's issue about what his users need and why. That's more easily handled with sets. No ebuild writing skills are needed and there's no danger of atoms being accidentally added to the set. -- Neil Bothwick *Libra*: /(Sept 23--Oct 23)/ An unfortunate typo on your application results in your being accepted into the Legion Of Superherpes. signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 12:55:19 -0500, Michael Orlitzky wrote: New behavior: user error permanently breaks your world file. It is not permanently broken, that implies it would stop the system working. It is merely damaged, and repairable. It may take a little effort to repair, but that will help you remember to be more careful in future. -- Neil Bothwick I can picture in my mind a world without war, a world without hate. And I can picture us attacking that world, because they'd never expect it. signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 03:50 PM, Neil Bothwick wrote: On Mon, 02 Jan 2012 12:55:19 -0500, Michael Orlitzky wrote: New behavior: user error permanently breaks your world file. It is not permanently broken, that implies it would stop the system working. It is merely damaged, and repairable. It may take a little effort to repair, but that will help you remember to be more careful in future. No one has offered up a way to fix it yet, or a downside to the old behavior. Making your software punish its users isn't going to make them more careful, it's going to make them stop using your software. If bash did an 'rm -rf /' when you mistyped a command[1], would you think, gee, I need to be more careful? Or would you think the guy who made it do that was an asshole? [1] There is distro that does this, even though it's an extreme example.
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 11:33:43 -0500 Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 11:16 AM, Michael Mol wrote: Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Make a backup copy of your world file. 1a. Remove those four lines. 2a. emerge -p --depclean 3a. Did any of those show up in the to-be-removed set? Add them back. Alternately: 1b. emerge -pev --tree --with-bdeps=y @world 2b Find those packages in the output. The tree form of the display will help you see if anything is depending on them. 3b. If anything is depending on them, you should be able to safely remove them from your world file. I'd follow up with the 1a, 2a, 3a solution to be sure. Sorry, but these won't work. Let's say that dev-php/PEAR-Mail_Mime has a dependency on dev-php/PEAR-Mail, but I have a customer who needs dev-php/PEAR-Mail for a contact form. Following your process, I would remove dev-php/PEAR-Mail from my world file. If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove PEAR-Mail and break the guy's site. cocktail Neil's suggestion of sets sounds like what you want here. Unfortunately it only works smoothly on first emerge (later on you have to dig through dep graphs to find the full dep list): First run emerge -p to find all the packages that will be pulled in, and add the whole lot to a set with a clear name that indicates it's function. Then emerge that set. As you discover further deps you can manually add them to the set It's quite a lot of extra work and you have to remember to do it, but it has the benefit of being somewhat self-documenting, at least in terms of having a record of what set pulled a package in initially. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 04:11 PM, Alan McKinnon wrote: cocktail Neil's suggestion of sets sounds like what you want here. Unfortunately it only works smoothly on first emerge (later on you have to dig through dep graphs to find the full dep list): First run emerge -p to find all the packages that will be pulled in, and add the whole lot to a set with a clear name that indicates it's function. Then emerge that set. As you discover further deps you can manually add them to the set It's quite a lot of extra work and you have to remember to do it, but it has the benefit of being somewhat self-documenting, at least in terms of having a record of what set pulled a package in initially. Requires time travel, not a solution!
Re: [gentoo-user] emerge --update behavior
On Mon, 2 Jan 2012 23:11:03 +0200, Alan McKinnon wrote: Neil's suggestion of sets sounds like what you want here. Unfortunately it only works smoothly on first emerge (later on you have to dig through dep graphs to find the full dep list): As it is only used to support non-portage installs, there isn't that much work involved, usually only looking at the README, adding the relevant packages to a set and emerging the set. Unless the out-of-tree packages dependencies change, there's no real maintenance to do, unless portage goes and upgrades a dep to a newer and incompatible version. -- Neil Bothwick If bankers can count, how come they have eight windows and only four tellers? signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 16:08:44 -0500, Michael Orlitzky wrote: It is not permanently broken, that implies it would stop the system working. It is merely damaged, and repairable. It may take a little effort to repair, but that will help you remember to be more careful in future. No one has offered up a way to fix it yet, or a downside to the old behavior. Yes they have. Remove anything in the least suspect and emerge -cp. Then emerge -n anything listed that you need. There was a script floating around that created a new world file that contained all installed packages that were not a dependency of another installed package. It's not a perfect fix, but pretty close. Found it: http://forums.gentoo.org/viewtopic-p-6861484.html -- Neil Bothwick The law of Probability Dispersal decrees that whatever it is that hits the fan will not be evenly distributed. signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 16:18:23 -0500, Michael Orlitzky wrote: Requires time travel, not a solution! Fine. Stick with your broken system and ignore any suggestions to either repair the damage you have already done or to avoid future damage. Blame it all on the portage devs and demand a refund! -- Neil Bothwick Fragile. Do not turn umop ap1sdn! signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 04:25 PM, Neil Bothwick wrote: On Mon, 02 Jan 2012 16:08:44 -0500, Michael Orlitzky wrote: No one has offered up a way to fix it yet, or a downside to the old behavior. Yes they have. Remove anything in the least suspect and emerge -cp. Then emerge -n anything listed that you need. I don't know which ones I need, and I can't just remove them and cross my fingers, because these are live servers. There was a script floating around that created a new world file that contained all installed packages that were not a dependency of another installed package. It's not a perfect fix, but pretty close. I gave a concrete example from one of our web servers where this would remove something important.
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 04:11 PM, Alan McKinnon wrote: cocktail Neil's suggestion of sets sounds like what you want here. Unfortunately it only works smoothly on first emerge (later on you have to dig through dep graphs to find the full dep list): First run emerge -p to find all the packages that will be pulled in, and add the whole lot to a set with a clear name that indicates it's function. Then emerge that set. As you discover further deps you can manually add them to the set It's quite a lot of extra work and you have to remember to do it, but it has the benefit of being somewhat self-documenting, at least in terms of having a record of what set pulled a package in initially. Requires time travel, not a solution! Seriously. Do you want a solution, or do you just want to rant about a change to the behavior of --update? Without some existing log of the things your existing customers specifically need, and without some means to intuit what they need by the web apps they've uploaded to their accounts, there isn't going to be any solution that isn't going to involve either a risk of breakage to your existing clients' sites, preservation of your damaged world file as an assume this is what I need set, or a great deal of work coming up with the list of things you actually need. Without that request log, you're in a *recovery* scenario, and there is no quick fix. All solutions offered that aren't time travel (better termed, change your practices so this doesn't happen again), are going to require a lot of effort and legwork on your part, and will *all* carry risk. Here's another time travel solution, but this one doesn't require changing past actions: Go through your log files and look for 'Updating world file, and look at what portage was doing at the time. Go through your emails with your customers and identify which packages they requested. Look at your own public-facing website and look at the list of packages you promise. If you either have all your emerge logs, or all your customer contact logs, it's doable. -- :wq
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 04:28 PM, Neil Bothwick wrote: On Mon, 02 Jan 2012 16:18:23 -0500, Michael Orlitzky wrote: Requires time travel, not a solution! Fine. Stick with your broken system and ignore any suggestions to either repair the damage you have already done or to avoid future damage. Blame it all on the portage devs and demand a refund! I'm not blaming anyone, and the portage devs don't personally owe me anything. I see an opportunity to make portage safer for all Gentoo users, and am trying to make my case here, don't take it personally. I appreciate the suggestions, but I already know how to avoid the problem in the future. But, if ever you make a single mistake, those solutions go out the window because you can no longer say what in the world file is important.
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 04:34 PM, Michael Mol wrote: On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzkymich...@orlitzky.com wrote: On 01/02/2012 04:11 PM, Alan McKinnon wrote: cocktail Neil's suggestion of sets sounds like what you want here. Unfortunately it only works smoothly on first emerge (later on you have to dig through dep graphs to find the full dep list): First run emerge -p to find all the packages that will be pulled in, and add the whole lot to a set with a clear name that indicates it's function. Then emerge that set. As you discover further deps you can manually add them to the set It's quite a lot of extra work and you have to remember to do it, but it has the benefit of being somewhat self-documenting, at least in terms of having a record of what set pulled a package in initially. Requires time travel, not a solution! Seriously. Do you want a solution, or do you just want to rant about a change to the behavior of --update? All I originally wanted to know was if anyone had a real reason to prefer the current behavior over the old. I've shown that there's a problem with the current behavior; if there are no real problems with the old behavior, then it's worth raising the issue. I know how to avoid the problem in the future, but there are plenty of other Gentoo users who don't, and who also won't be able to fix today's mistakes a year from now.
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 4:48 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 04:34 PM, Michael Mol wrote: On Mon, Jan 2, 2012 at 4:18 PM, Michael Orlitzkymich...@orlitzky.com wrote: On 01/02/2012 04:11 PM, Alan McKinnon wrote: cocktail Neil's suggestion of sets sounds like what you want here. Unfortunately it only works smoothly on first emerge (later on you have to dig through dep graphs to find the full dep list): First run emerge -p to find all the packages that will be pulled in, and add the whole lot to a set with a clear name that indicates it's function. Then emerge that set. As you discover further deps you can manually add them to the set It's quite a lot of extra work and you have to remember to do it, but it has the benefit of being somewhat self-documenting, at least in terms of having a record of what set pulled a package in initially. Requires time travel, not a solution! Seriously. Do you want a solution, or do you just want to rant about a change to the behavior of --update? All I originally wanted to know was if anyone had a real reason to prefer the current behavior over the old. Ah. I must have gotten confused at So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. I've shown that there's a problem with the current behavior; if there are no real problems with the old behavior, then it's worth raising the issue. Ah. Then based on the conversation thus far, it sounds like you'd have to ask the developer who made the change. I know how to avoid the problem in the future, but there are plenty of other Gentoo users who don't, and who also won't be able to fix today's mistakes a year from now. -- :wq
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 04:58 PM, Michael Mol wrote: Ah. I must have gotten confused at So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Sorry, this thread has gotten a little out of hand =) I think my point was: most solutions available to me now involve potential breakage. Others require me to be more careful 6 years ago. Neither of those is desirable. The current --update behavior makes this situation easy to get into. If there are no downsides to the old behavior (the point of this thread), then I think the old behavior is preferable.
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 16:33:04 -0500, Michael Orlitzky wrote: Yes they have. Remove anything in the least suspect and emerge -cp. Then emerge -n anything listed that you need. I don't know which ones I need, and I can't just remove them and cross my fingers, because these are live servers. You remove them from the world file, not the system. Then run emerge -cp to seen what would be depcleaned. Nothing is uninstalled and nothing stops working. There was a script floating around that created a new world file that contained all installed packages that were not a dependency of another installed package. It's not a perfect fix, but pretty close. I gave a concrete example from one of our web servers where this would remove something important. How so? If anything that was not a dependency of something else was in the world file, how could anything be removed? -- Neil Bothwick I'm not a complete idiot - several parts are missing. signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 5:13 PM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 04:58 PM, Michael Mol wrote: Ah. I must have gotten confused at So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Sorry, this thread has gotten a little out of hand =) I think my point was: most solutions available to me now involve potential breakage. Others require me to be more careful 6 years ago. Neither of those is desirable. The current --update behavior makes this situation easy to get into. If there are no downsides to the old behavior (the point of this thread), then I think the old behavior is preferable. I'd guess it's more architectural wrt the internals of portage. But that's why I figure you'd have to ask the devs... -- :wq
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 05:41 PM, Neil Bothwick wrote: On Mon, 02 Jan 2012 16:33:04 -0500, Michael Orlitzky wrote: Yes they have. Remove anything in the least suspect and emerge -cp. Then emerge -n anything listed that you need. I don't know which ones I need, and I can't just remove them and cross my fingers, because these are live servers. You remove them from the world file, not the system. Then run emerge -cp to seen what would be depcleaned. Nothing is uninstalled and nothing stops working. There was a script floating around that created a new world file that contained all installed packages that were not a dependency of another installed package. It's not a perfect fix, but pretty close. I gave a concrete example from one of our web servers where this would remove something important. How so? If anything that was not a dependency of something else was in the world file, how could anything be removed? I have both of these in world: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime Let's say PEAR-Mail_Mime depends on PEAR-Mail -- it might, I haven't checked, it's just an example. And I remember installing PEAR-Mail_Mime: I needed it to receive binary attachments through a contact form on an internal site. I suspect a customer had me install PEAR-Mail so that he could send some notifications via SMTP rather than sendmail(). Can I remove it from world? At the moment, yes I can: PEAR-Mail_Mime depends on PEAR-Mail, so there will be no change in my --depclean output. But if I ever take down the internal site, and uninstall PEAR-Mail_Mime, depclean will want to remove PEAR-Mail, and break that guy's site. This is what that script would do. If I know that I have been careful in the past, this is not a problem, since the contents of world will be accurate. However, I'm a little worried that I may have forgotten --oneshot and added PEAR-Mail by mistake on an upgrade. Now, I have to either risk breaking some customer's site, or leave PEAR-Mail in my world file forever.
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 16:18:23 -0500 Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 04:11 PM, Alan McKinnon wrote: cocktail Neil's suggestion of sets sounds like what you want here. Unfortunately it only works smoothly on first emerge (later on you have to dig through dep graphs to find the full dep list): First run emerge -p to find all the packages that will be pulled in, and add the whole lot to a set with a clear name that indicates it's function. Then emerge that set. As you discover further deps you can manually add them to the set It's quite a lot of extra work and you have to remember to do it, but it has the benefit of being somewhat self-documenting, at least in terms of having a record of what set pulled a package in initially. Requires time travel, not a solution! Eh? Did you read what I wrote? You don't have to go back and figure it all out all over again, emerge -p something tells you what needs to be emerged. Paste-edit that into a set file and Bob's your Auntie. What are you looking for here? Do you seek a magic way for portage to know what you intended and why you did what you did when you did it? Software can't do that. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 16:08:44 -0500 Michael Orlitzky mich...@orlitzky.com wrote: Making your software punish its users isn't going to make them more careful, it's going to make them stop using your software. If bash did an 'rm -rf /' when you mistyped a command[1], would you think, gee, I need to be more careful? Or would you think the guy who made it do that was an asshole? That's an interesting question. Moving slightly OT, I think most of the devs who worked on portage in the past (starting with Daniel) have little clue about proper design and just slapped stuff/features on with little thought. It might not actually BE that way, but it sure LOOKS like it. And now finally we have Zac, a brave man who has taken on the thankless task of sorting the mess out. Most of his deep changes over the past two years or so are to make things consistent within the overall grand plan. Stuff breaks badly when you do that. But it has to be done. Today it's your turn to be on the sharp end. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 18:11:15 -0500 Michael Orlitzky mich...@orlitzky.com wrote: If I know that I have been careful in the past, this is not a problem, since the contents of world will be accurate. However, I'm a little worried that I may have forgotten --oneshot and added PEAR-Mail by mistake on an upgrade. Now, I have to either risk breaking some customer's site, or leave PEAR-Mail in my world file forever. TwoIf I know that I have been careful in the past, this is not a problem, since the contents of world will be accurate. However, I'm a little worried that I may have forgotten --oneshot and added PEAR-Mail by mistake on an upgrade. Now, I have to either risk breaking some customer's site, or leave PEAR-Mail in my world file forever. questions: 1. How do you propose any possible software could help with this? 2. Why do you care about those specific packages in world? Do they cause a conflict or some other large problem? Personally I'd just leave them in world -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On Mon, 2 Jan 2012 11:20:19 -0500 Michael Mol mike...@gmail.com wrote: On Mon, Jan 2, 2012 at 11:16 AM, Michael Mol mike...@gmail.com wrote: On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 11:01 AM, Mark Knecht wrote: I tell by knowing which files I want in @world. Everything in world should be a package __I__ specifically want to use. Everything in world (on my machines anyway) is something: 1) I'd call from the command line 2) Need to write a little software myself, most specifically a library 3) Aid in displaying things, like font packages 4) Something required by Gentoo that I don't totally understand, like a virtual package. I just look through every so often and make sure everything seems to meet those sorts of requirements. When I find a library or something else then: 1) I make sure I'm clean with emerge -DuN @world AND emerge -p --depclean 2) I'll delete the questionable item 3) I'll see what happens with the two commands in #1 To me it's pretty straight forward, but I'm also not bothered at all by the idea that emerge package and emerge -u package do the same thing. A machine that doesn't have a package, when updated, should have the package and it should (IMO) be in world, but that's just me. Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Make a backup copy of your world file. 1a. Remove those four lines. 2a. emerge -p --depclean 3a. Did any of those show up in the to-be-removed set? Add them back. Alternately: 1b. emerge -pev --tree --with-bdeps=y @world 2b Find those packages in the output. The tree form of the display will help you see if anything is depending on them. 3b. If anything is depending on them, you should be able to safely remove them from your world file. I'd follow up with the 1a, 2a, 3a solution to be sure. It just occurred to me...in the future, you might be able to build ebuilds for managing customer requests, to ensure that dependencies on particular packages with USE flags and version requirements are met. I haven't built ebuilds myself yet, but it's on my TODO list. It's quite easy actually, doubly so if the package follows some sane rational build process (like eg configure make make install). In that case the ebuild is very small as the portage framework does all the heavy lifting automagically. I'd move that TODO item higher up on the priority list if I were you, you'll be glad you did :-) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 06:29 PM, Alan McKinnon wrote: On Mon, 02 Jan 2012 18:11:15 -0500 Michael Orlitzkymich...@orlitzky.com wrote: If I know that I have been careful in the past, this is not a problem, since the contents of world will be accurate. However, I'm a little worried that I may have forgotten --oneshot and added PEAR-Mail by mistake on an upgrade. Now, I have to either risk breaking some customer's site, or leave PEAR-Mail in my world file forever. TwoIf I know that I have been careful in the past, this is not a problem, since the contents of world will be accurate. However, I'm a little worried that I may have forgotten --oneshot and added PEAR-Mail by mistake on an upgrade. Now, I have to either risk breaking some customer's site, or leave PEAR-Mail in my world file forever. questions: 1. How do you propose any possible software could help with this? Well, before the change to --update, I kept all of my world files clean for years. The problem still would have existed if I had screwed up, but it was much harder to screw up. Software can't help at this point. That is, ultimately, my reason for preferring the old behavior. Just the knowledge that it is easy to accidentally add a package to world makes it dangerous to clean up manually. I think, Maybe I added this accidentally, since it's so easy to forget --oneshot. Better leave it alone. 2. Why do you care about those specific packages in world? Do they cause a conflict or some other large problem? Personally I'd just leave them in world That's the plan. Most of these servers have been running forever. I've never reformatted a gentoo box. If every once in a while a package gets added to world, it's not a problem today or tomorrow, but it might be in ten years if these boxes are still up -- and I expect some of them to be.
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 06:25 PM, Alan McKinnon wrote: On Mon, 02 Jan 2012 16:08:44 -0500 Michael Orlitzkymich...@orlitzky.com wrote: Making your software punish its users isn't going to make them more careful, it's going to make them stop using your software. If bash did an 'rm -rf /' when you mistyped a command[1], would you think, gee, I need to be more careful? Or would you think the guy who made it do that was an asshole? That's an interesting question. Moving slightly OT, I think most of the devs who worked on portage in the past (starting with Daniel) have little clue about proper design and just slapped stuff/features on with little thought. It might not actually BE that way, but it sure LOOKS like it. And now finally we have Zac, a brave man who has taken on the thankless task of sorting the mess out. Most of his deep changes over the past two years or so are to make things consistent within the overall grand plan. Stuff breaks badly when you do that. But it has to be done. Today it's your turn to be on the sharp end. I'm fine with suffering a little for the greater good, but is the new behavior better in any tangible way?
Re: [gentoo-user] emerge --update behavior
On Mon, Jan 2, 2012 at 6:33 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Mon, 2 Jan 2012 11:20:19 -0500 Michael Mol mike...@gmail.com wrote: On Mon, Jan 2, 2012 at 11:16 AM, Michael Mol mike...@gmail.com wrote: On Mon, Jan 2, 2012 at 11:09 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 01/02/2012 11:01 AM, Mark Knecht wrote: I tell by knowing which files I want in @world. Everything in world should be a package __I__ specifically want to use. Everything in world (on my machines anyway) is something: 1) I'd call from the command line 2) Need to write a little software myself, most specifically a library 3) Aid in displaying things, like font packages 4) Something required by Gentoo that I don't totally understand, like a virtual package. I just look through every so often and make sure everything seems to meet those sorts of requirements. When I find a library or something else then: 1) I make sure I'm clean with emerge -DuN @world AND emerge -p --depclean 2) I'll delete the questionable item 3) I'll see what happens with the two commands in #1 To me it's pretty straight forward, but I'm also not bothered at all by the idea that emerge package and emerge -u package do the same thing. A machine that doesn't have a package, when updated, should have the package and it should (IMO) be in world, but that's just me. Fine for your home PC, doesn't cut it on servers. I have the following in one of my world files: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime dev-php/PEAR-PEAR dev-php/PEAR-Structures_Graph which of those do I want? At least one of them was installed to support a customer's custom PHP application. Maybe all of them were and they all belong in world. No one knows, this server is older than the current --update behavior. So which ones can I remove? Solutions involving time travel and/or losing customers will be disqualified. Make a backup copy of your world file. 1a. Remove those four lines. 2a. emerge -p --depclean 3a. Did any of those show up in the to-be-removed set? Add them back. Alternately: 1b. emerge -pev --tree --with-bdeps=y @world 2b Find those packages in the output. The tree form of the display will help you see if anything is depending on them. 3b. If anything is depending on them, you should be able to safely remove them from your world file. I'd follow up with the 1a, 2a, 3a solution to be sure. It just occurred to me...in the future, you might be able to build ebuilds for managing customer requests, to ensure that dependencies on particular packages with USE flags and version requirements are met. I haven't built ebuilds myself yet, but it's on my TODO list. It's quite easy actually, doubly so if the package follows some sane rational build process (like eg configure make make install). In that case the ebuild is very small as the portage framework does all the heavy lifting automagically. I'd move that TODO item higher up on the priority list if I were you, you'll be glad you did :-) Oh, I know. There's a bunch of things I want to add or fix. Even if that means taking some degree of ownership of them. -- :wq
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 18:11:15 -0500, Michael Orlitzky wrote: How so? If anything that was not a dependency of something else was in the world file, how could anything be removed? I have both of these in world: dev-php/PEAR-Mail dev-php/PEAR-Mail_Mime Let's say PEAR-Mail_Mime depends on PEAR-Mail -- it might, I haven't checked, it's just an example. And I remember installing PEAR-Mail_Mime: I needed it to receive binary attachments through a contact form on an internal site. I suspect a customer had me install PEAR-Mail so that he could send some notifications via SMTP rather than sendmail(). Can I remove it from world? At the moment, yes I can: PEAR-Mail_Mime depends on PEAR-Mail, so there will be no change in my --depclean output. But if I ever take down the internal site, and uninstall PEAR-Mail_Mime, depclean will want to remove PEAR-Mail, and break that guy's site. This is what that script would do. If I know that I have been careful in the past, this is not a problem, since the contents of world will be accurate. However, I'm a little worried that I may have forgotten --oneshot and added PEAR-Mail by mistake on an upgrade. Now, I have to either risk breaking some customer's site, or leave PEAR-Mail in my world file forever. nothing can protect you from something going wrong with this. What if you had installed dev-php/PEAR-Mail_Mime first? It would have pulled in dev-php/PEAR-Mail and you would not have had to install that for the other customer and it would not be in world. If the first customer no longer needs his packages, dev-php/PEAR-Mail would still be subject to depcleaning, no matter how emerge -u behaved. Where you have a situation where packages are dependencies of factors outside of portage, you have to take your own steps to manage this. The only software that can completely help you with that is already installed between your ears. As stated previously, I would use sets as a self-documenting method of doing this, but anything involving adequate record keeping should do. As Alan indicated, there is no real harm in having the odd spurious package in world aside from a tendency to bloat. -- Neil Bothwick What do you get if you cross an agnostic, an insomniac and adyslexic? Someone who lies awake at night wondering if there really is a dog. signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 18:49:50 -0500, Michael Orlitzky wrote: And now finally we have Zac, a brave man who has taken on the thankless task of sorting the mess out. Most of his deep changes over the past two years or so are to make things consistent within the overall grand plan. Stuff breaks badly when you do that. But it has to be done. Today it's your turn to be on the sharp end. I'm fine with suffering a little for the greater good, but is the new behavior better in any tangible way? It is reasonable to assume that the answer to that question is yes. Any other answer raises the question why did Zac spend so much effort recoding portage just to piss off the odd user?. -- Neil Bothwick Linux users do it without paying a Bill signature.asc Description: PGP signature
Re: [gentoo-user] emerge --update behavior
Neil Bothwick wrote: On Mon, 02 Jan 2012 18:49:50 -0500, Michael Orlitzky wrote: And now finally we have Zac, a brave man who has taken on the thankless task of sorting the mess out. Most of his deep changes over the past two years or so are to make things consistent within the overall grand plan. Stuff breaks badly when you do that. But it has to be done. Today it's your turn to be on the sharp end. I'm fine with suffering a little for the greater good, but is the new behavior better in any tangible way? It is reasonable to assume that the answer to that question is yes. Any other answer raises the question why did Zac spend so much effort recoding portage just to piss off the odd user?. I always knew I was odd. Looks like I have some company tho. Welcome to the odd user group Michael. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 07:04 PM, Neil Bothwick wrote: On Mon, 02 Jan 2012 18:49:50 -0500, Michael Orlitzky wrote: And now finally we have Zac, a brave man who has taken on the thankless task of sorting the mess out. Most of his deep changes over the past two years or so are to make things consistent within the overall grand plan. Stuff breaks badly when you do that. But it has to be done. Today it's your turn to be on the sharp end. I'm fine with suffering a little for the greater good, but is the new behavior better in any tangible way? It is reasonable to assume that the answer to that question is yes. Any other answer raises the question why did Zac spend so much effort recoding portage just to piss off the odd user?. Hah! Many people here are probably employed in IT, software development, or system administration where the job description can be summed up as unfixing things that weren't broken. We all implicitly trust the devs with our systems, of course, but maybe it was announced to little protest and that was reason enough?
Re: [gentoo-user] emerge --update behavior
On 01/02/2012 07:22 PM, Dale wrote: I always knew I was odd. Looks like I have some company tho. Welcome to the odd user group Michael. It ain't us =)
Re: [gentoo-user] emerge --update behavior
On Mon, 02 Jan 2012 18:48:48 -0500 Michael Orlitzky mich...@orlitzky.com wrote: 2. Why do you care about those specific packages in world? Do they cause a conflict or some other large problem? Personally I'd just leave them in world That's the plan. Most of these servers have been running forever. I've never reformatted a gentoo box. If every once in a while a package gets added to world, it's not a problem today or tomorrow, but it might be in ten years if these boxes are still up -- and I expect some of them to be. The way I see it there are actually two issues here, and the thread is conflating them. One is maintaining what is in world, dealing with bloat if it happens, and depcleaning stuffs. All this is the province of portage. The other is *why* you put that package there in the first place because now you must maintain it. You chose to install a lowish level lib for reasons of your own and forgot to document it and portage cannot help you. So your actual problem is that you relied on an arbitrary behaviour of portage from the days when the standard was whatever portage does today and you are unhappy because for you that is now broken. But no-one ever promised you that behaviour in a stable API. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge --update behavior
On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzky mich...@orlitzky.com wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. Pretty sure that's what -1 is for. I'm just getting the hang of it myself. -- :wq
Re: [gentoo-user] emerge --update behavior
Michael Orlitzky wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. We noticed that a while back too. I added --oneshot to my make.conf setting to prevent this. When you want something added to the world file, check into the --select option. I'm pretty sure that is the one. I do agree that updates shouldn't add things to the world file but I wouldn't hold my breath on it getting changed. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] emerge --update behavior
On 01/01/2012 05:06 PM, Michael Mol wrote: On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzkymich...@orlitzky.com wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. Pretty sure that's what -1 is for. I'm just getting the hang of it myself. Well, I know what I'm *supposed* to do. My complaint is basically that I sometimes forget to add -1 with -u, and that bad things happen as a result. But why should I have to add -1 along with it? Is there any reason you would ever want -u to add a package to your world file? If not, we can avoid headaches in the future by making it do the sane (not harmful) thing.
Re: [gentoo-user] emerge --update behavior
Michael Orlitzky wrote: On 01/01/2012 05:06 PM, Michael Mol wrote: On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzkymich...@orlitzky.com wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. Pretty sure that's what -1 is for. I'm just getting the hang of it myself. Well, I know what I'm *supposed* to do. My complaint is basically that I sometimes forget to add -1 with -u, and that bad things happen as a result. But why should I have to add -1 along with it? Is there any reason you would ever want -u to add a package to your world file? If not, we can avoid headaches in the future by making it do the sane (not harmful) thing. Using -u used to work the way you describe but that was a while ago. The only thing I know of is to add --oneshot to make.conf so you don't forget. I think they knew this was going to be a issue. This is in man emerge: --select [ y | n ] Add specified packages to the world set (inverse of --oneshot). This is useful if you want to use EMERGE_DEFAULT_OPTS to make --oneshot behavior default. The way I read that is that they expect you to add --oneshot to make.conf. Like you, this makes no sense to me. I would rather they leave it the way it was and then not needed the --select option at all. :/ Then again, they add confusion so we can fix it in make.conf. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] emerge --update behavior
On Sun, Jan 1, 2012 at 2:31 PM, Dale rdalek1...@gmail.com wrote: Michael Orlitzky wrote: On 01/01/2012 05:06 PM, Michael Mol wrote: On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzkymich...@orlitzky.com wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. Pretty sure that's what -1 is for. I'm just getting the hang of it myself. Well, I know what I'm *supposed* to do. My complaint is basically that I sometimes forget to add -1 with -u, and that bad things happen as a result. But why should I have to add -1 along with it? Is there any reason you would ever want -u to add a package to your world file? If not, we can avoid headaches in the future by making it do the sane (not harmful) thing. Using -u used to work the way you describe but that was a while ago. The only thing I know of is to add --oneshot to make.conf so you don't forget. I think they knew this was going to be a issue. This is in man emerge: --select [ y | n ] Add specified packages to the world set (inverse of --oneshot). This is useful if you want to use EMERGE_DEFAULT_OPTS to make --oneshot behavior default. The way I read that is that they expect you to add --oneshot to make.conf. Like you, this makes no sense to me. I would rather they leave it the way it was and then not needed the --select option at all. :/ Then again, they add confusion so we can fix it in make.conf. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n I'm not clear. Why does one ever bother with emerge -u package? In 10 years of Gentoo I've managed to get by with basically either emerge package to add something or emerge -DuN @world to stay updated. (or @system in the old days but no longer...) Not picking on anyone but in my mind emerge -u package _should_ add the package to the world file because any time I run emerge with a package name and without -1 I'm telling it to make it part of @world. If it's not part of @world, and is already on the machine, then emerge -DuN @world is the right way to get it and everything else updated. Just curious... - Mark
Re: [gentoo-user] emerge --update behavior
Mark Knecht wrote: On Sun, Jan 1, 2012 at 2:31 PM, Dalerdalek1...@gmail.com wrote: Michael Orlitzky wrote: On 01/01/2012 05:06 PM, Michael Mol wrote: On Sun, Jan 1, 2012 at 4:50 PM, Michael Orlitzkymich...@orlitzky.com wrote: Using emerge --update foo adds foo to your world file. This is responsible for pretty much every package that incorrectly found its way into one of my world files. Is there any reason to desire the current behavior? I'd like to suggest that it be fixed, but want to be sure I'm not just being short-sighted. Pretty sure that's what -1 is for. I'm just getting the hang of it myself. Well, I know what I'm *supposed* to do. My complaint is basically that I sometimes forget to add -1 with -u, and that bad things happen as a result. But why should I have to add -1 along with it? Is there any reason you would ever want -u to add a package to your world file? If not, we can avoid headaches in the future by making it do the sane (not harmful) thing. Using -u used to work the way you describe but that was a while ago. The only thing I know of is to add --oneshot to make.conf so you don't forget. I think they knew this was going to be a issue. This is in man emerge: --select [ y | n ] Add specified packages to the world set (inverse of --oneshot). This is useful if you want to use EMERGE_DEFAULT_OPTS to make --oneshot behavior default. The way I read that is that they expect you to add --oneshot to make.conf. Like you, this makes no sense to me. I would rather they leave it the way it was and then not needed the --select option at all. :/ Then again, they add confusion so we can fix it in make.conf. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n I'm not clear. Why does one ever bother with emerge -u package? In 10 years of Gentoo I've managed to get by with basically either emerge package to add something or emerge -DuN @world to stay updated. (or @system in the old days but no longer...) Not picking on anyone but in my mind emerge -u package _should_ add the package to the world file because any time I run emerge with a package name and without -1 I'm telling it to make it part of @world. If it's not part of @world, and is already on the machine, then emerge -DuN @world is the right way to get it and everything else updated. Just curious... - Mark Sometimes I do my updates one package at a time. I would then use the -u option so that it would be updated, not added to world. To me, update means update. If there is no option then it should be installed and added to world. That is how it was done for a good long while then got changed. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
