Re: [gentoo-user] Re: package.keywords
On Tuesday 23 June 2009 01:17:16 Dale wrote: Neil Bothwick wrote: On Mon, 22 Jun 2009 15:51:31 + (UTC), James wrote: I'm mostly running stable with exceptions being enabled via the /etc/portage file structure. Usually it's small, but now with kde4, BLOAT is my modus operandi, not by choice.. It's easier to manage if you make portage.keywords a directory then put the actual packages in files within that directory. That way you can separate the files needed to run KDE4 from any other group of packages. All package.* files in /etc/portage can be replaced a directories, then all the files in that directory are considered as a whole. For some reason, my light bulb has still not came on so here comes some questions. I would create /etc/portage/package.keywords then inside that another directory or a set of files? Say, one named KDE4 to put all of KDE4 and it's little friends and then another for some other set of packages? Is this sort of like the sets thing which I am still curious about? Yes, precisely. If package.keywords is a single file, then all your keywords must be in that file. This is difficult for ebuilds to manipulate, and difficult for you to edit too. If I send you my list of KDE keywords, you have to copy paste the lot into a file and put comments at the start and end so you know what it all is. If package.keywords is a directory, then portage/ebuilds/tools/you can add and remove entire files easily, leaving everything else untouched. Right now, package.keywords and friends are files not directories. Maybe tarring up your portage directory and emailing me off list would help? I need a light bulb moment here. :/ It's easy. As root: cd /etc/portage mv package.keywords package.keywords~ mkdir package.keywords mv package.keywords~ package.keywords/package.keywords The destination file in the last command can be named anything you like. Now, if you install enlightenment, create and edit /etc/portage/package.keywords/e17 If I send you my KDE keywords as an attachment, right-click, Save As, /etc/portage/package.keywords/kde4 Done, sorted. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: package.keywords
Alan McKinnon wrote: On Tuesday 23 June 2009 01:17:16 Dale wrote: Neil Bothwick wrote: On Mon, 22 Jun 2009 15:51:31 + (UTC), James wrote: I'm mostly running stable with exceptions being enabled via the /etc/portage file structure. Usually it's small, but now with kde4, BLOAT is my modus operandi, not by choice.. It's easier to manage if you make portage.keywords a directory then put the actual packages in files within that directory. That way you can separate the files needed to run KDE4 from any other group of packages. All package.* files in /etc/portage can be replaced a directories, then all the files in that directory are considered as a whole. For some reason, my light bulb has still not came on so here comes some questions. I would create /etc/portage/package.keywords then inside that another directory or a set of files? Say, one named KDE4 to put all of KDE4 and it's little friends and then another for some other set of packages? Is this sort of like the sets thing which I am still curious about? Yes, precisely. If package.keywords is a single file, then all your keywords must be in that file. This is difficult for ebuilds to manipulate, and difficult for you to edit too. If I send you my list of KDE keywords, you have to copy paste the lot into a file and put comments at the start and end so you know what it all is. If package.keywords is a directory, then portage/ebuilds/tools/you can add and remove entire files easily, leaving everything else untouched. Right now, package.keywords and friends are files not directories. Maybe tarring up your portage directory and emailing me off list would help? I need a light bulb moment here. :/ It's easy. As root: cd /etc/portage mv package.keywords package.keywords~ mkdir package.keywords mv package.keywords~ package.keywords/package.keywords The destination file in the last command can be named anything you like. Now, if you install enlightenment, create and edit /etc/portage/package.keywords/e17 If I send you my KDE keywords as an attachment, right-click, Save As, /etc/portage/package.keywords/kde4 Done, sorted. This sounds cool. I don't unmask a lot or anything but something like KDE 4 comes to mind for this. That requires a lot of work. I'm going to have to check to see if autounmask supports this too. Thanks much. Light bulb is glowing a bit now. o_O Dale :-) :-)
Re: [gentoo-user] Re: package.keywords
On Tue, 23 Jun 2009 01:51:45 -0500, Dale wrote: This sounds cool. I don't unmask a lot or anything but something like KDE 4 comes to mind for this. That requires a lot of work. I'm going to have to check to see if autounmask supports this too. It does, it creates a file called autounmask-something, so it is obvious where it came from and what it unmasks. -- Neil Bothwick Good fortune will find you provided you left clear instructions. signature.asc Description: PGP signature
Re: [gentoo-user] Re: package.keywords
Neil Bothwick wrote: On Tue, 23 Jun 2009 01:51:45 -0500, Dale wrote: This sounds cool. I don't unmask a lot or anything but something like KDE 4 comes to mind for this. That requires a lot of work. I'm going to have to check to see if autounmask supports this too. It does, it creates a file called autounmask-something, so it is obvious where it came from and what it unmasks. It's been a while since I used it but I thought I saw a update being done a while back. May try KDE 4 again soon. The biggest thing I hate about KDE 4 is the login screen. Dale :-) :-)
Re: [gentoo-user] Re: package.keywords
On Tuesday 23 June 2009 09:38:32 Dale wrote: Neil Bothwick wrote: On Tue, 23 Jun 2009 01:51:45 -0500, Dale wrote: This sounds cool. I don't unmask a lot or anything but something like KDE 4 comes to mind for this. That requires a lot of work. I'm going to have to check to see if autounmask supports this too. It does, it creates a file called autounmask-something, so it is obvious where it came from and what it unmasks. It's been a while since I used it but I thought I saw a update being done a while back. May try KDE 4 again soon. The biggest thing I hate about KDE 4 is the login screen. Well that's easy, just don't use kdm :-) If you want pretty, there's entrance If you want light, there's slim If you want hard-core, there's xdm There's also gdm. But I don't talk about gdm. It's personal, and painful. Don't ask :-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: package.keywords
Alan McKinnon wrote: There's also gdm. But I don't talk about gdm. It's personal, and painful. Don't ask :-) Well, tell us why you don't like gdm. :-) ;-p __ Information from ESET NOD32 Antivirus, version of virus signature database 4180 (20090623) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: [gentoo-user] Re: package.keywords
Alan McKinnon wrote: On Tuesday 23 June 2009 09:38:32 Dale wrote: Neil Bothwick wrote: On Tue, 23 Jun 2009 01:51:45 -0500, Dale wrote: This sounds cool. I don't unmask a lot or anything but something like KDE 4 comes to mind for this. That requires a lot of work. I'm going to have to check to see if autounmask supports this too. It does, it creates a file called autounmask-something, so it is obvious where it came from and what it unmasks. It's been a while since I used it but I thought I saw a update being done a while back. May try KDE 4 again soon. The biggest thing I hate about KDE 4 is the login screen. Well that's easy, just don't use kdm :-) If you want pretty, there's entrance If you want light, there's slim If you want hard-core, there's xdm There's also gdm. But I don't talk about gdm. It's personal, and painful. Don't ask :-) Well, what I don't like is the clock with no seconds. I have a changing background and I sort of like it to change on the 00's. I know exactly how long it takes for me to type in my password, hit return and it start the desktop. It's 11 seconds here. So, if I hit return right on 49 seconds, the background changes on the 00's every time. The new KDE login doesn't have a second hand so I have no idea when to hit the return key to login. I hate to say this, I may stick with KDE 3 until that is changed. There has to be a setting somewhere but this little idiot can't find it. I have never seen gdm so I'll take your word for it. I hate that little startx thing. That is ugly. O-o Dale :-) :-)
Re: [gentoo-user] Re: package.keywords
On Tue, 23 Jun 2009 10:27:37 +0200, Alan McKinnon wrote: Well that's easy, just don't use kdm :-) If you want pretty, there's entrance If you want light, there's slim If you want hard-core, there's xdm If you want lazy, use kdm with auto-login. -- Neil Bothwick .sig? we don't need no stinkin' .sig! signature.asc Description: PGP signature
Re: [gentoo-user] Re: package.keywords
On 6/22/09, James wirel...@tampabay.rr.com wrote: Arttu V. arttuv69 at gmail.com writes: More reading: ebuild(5) Ah, ok so there is not restriction on using any of the the boolean operators in any config file underneath /etc/portage? as section 5 does not mention any Well, for those files that are actually supposed to contain DEPEND atoms that is probably true. I haven't checked the whole man page and all files it lists to see if it places any restrictions on some specific files therein, so I'm a bit timid to claim full no limits either. But for package.keywords it didn't mention any limits and I'd believe the others don't have them either. :) Still, the best identifier of the allowed syntax is probably portage itself. Make a typo in files under /etc/portage and portage will tell you next time you emerge -pv something or emerge -av something. And it also breaks in a quite predictable fashion when it reads your typos in those files: it will just drop the lines it doesn't understand (while also printing warning messages) and then dutifully proceed to next line. So if ever in doubt, you can try it and see what portage's parser thinks about your fuzz-test. :) This is my (mis)conception, although, as you have suggest, there are (gentoo) cultural norms that do suggest certain boolean operations should not be used, in say for example, package.keywords? Not sure if by cultural norms you're referring to something I'd rather label as best practices? :) But then again, there are best practices for bleeding edge folks and best practices for stability is paramount folks and they may overlap, but most likely they aren't quite the same. I'm mostly running stable with exceptions being enabled via the /etc/portage file structure. Usually it's small, but now with kde4, BLOAT is my modus operandi, not by choice.. Then, again, you probably don't want the = as it will unmask the latest testing version currently available, plus in future any new testing grade versions as they get added to portage tree. What you want is either = or ~. (And do note that ~ at the front of a DEPEND atom means a different thing from the testing keyword in ~arch). But it is all up to you to decide, you're the commander'n'chief of your own boxen. -- Arttu V.
[gentoo-user] Re: package.keywords
Alan McKinnon alan.mckinnon at gmail.com writes: This is my (mis)conception, although, as you have suggest, there are (gentoo) cultural norms that do suggest certain boolean operations should not be used, in say for example, package.keywords? That's more just a safeguard against forgetting you put it there than anything else Good to know. The vast majority of cases will use only the = operator or nothing. That's so you unmask the one version you are interested in, not everything from here on out, including every buggy, pre-release and just plain broken version that happens to have an ebuild. So entries in package.keywords should just have the ~ in front of them? No point in using other boolean operations in the package.keywords file? The use-case for no operator is mostly for the case where you run say a stable box, and want the latest of a specific well-known package. You might want the latest Qt for example. Another example is -svn ebuilds - enlightenment is a case in point. The snapshots are always out of date, latest svn is pretty stable, so one must unmask everything to get the - versions Ok, now you just tossed my little (pee brain) around quite significantly... Your saying that not operator will get me the - (SVN) version of a package?And that this is most likely the most stable because the devs/hacks work on it often? If so then lets put it to the test. Maybee app-arch/xz-utils ? so my entry in /etc/portage/package.keywords should look like this: app-arch/xz-utils Nothing I tried in either package.keywords or package.unmask make the app-arch/xz-utils- (SVN) version available. So what did I miss? James
[gentoo-user] Re: package.keywords
On 06/23/2009 05:40 PM, James wrote: [...] So entries in package.keywords should just have the ~ in front of them? No point in using other boolean operations in the package.keywords file? There's a point to everything. You need to use whatever suits what you want to do. ~: This version and all revision bumps of it. =: This version. : Higher than this version. : Lower than this version. =: This and higher versions. =: This and lower versions. Note that revision bumps are not higher versions. For example: ~some-category/foo-3.0.10 will match foo-3.0.10, foo-3.0.10-r1, foo-3.0.10-r2 and all -rN versions of it, but will *not* match foo-3.0.11 nor 3.0.9. Just 3.0.10 and all revisions of it.
Re: [gentoo-user] Re: package.keywords
On Tue, 23 Jun 2009 14:40:51 + (UTC), James wrote: app-arch/xz-utils Nothing I tried in either package.keywords or package.unmask make the app-arch/xz-utils- (SVN) version available. This ebuild doesn't have a valid KEYWORDS line, try something less broken. -- Neil Bothwick Head: (n.) the part of a disk drive which detects sectors and decides which of the two possible values to return: 'lose a turn' or 'bankrupt.' signature.asc Description: PGP signature
Re: [gentoo-user] Re: package.keywords
On Tuesday 23 June 2009 16:40:51 James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: This is my (mis)conception, although, as you have suggest, there are (gentoo) cultural norms that do suggest certain boolean operations should not be used, in say for example, package.keywords? That's more just a safeguard against forgetting you put it there than anything else Good to know. The vast majority of cases will use only the = operator or nothing. That's so you unmask the one version you are interested in, not everything from here on out, including every buggy, pre-release and just plain broken version that happens to have an ebuild. So entries in package.keywords should just have the ~ in front of them? No point in using other boolean operations in the package.keywords file? I personally have never used other operators. But Murphy says that as soon as I say there's no need for them, someone will come along and prove me wrong :-) It's not a bad thing to have all operators be valid syntax, then you (the admin) can choose what you actually need The use-case for no operator is mostly for the case where you run say a stable box, and want the latest of a specific well-known package. You might want the latest Qt for example. Another example is -svn ebuilds - enlightenment is a case in point. The snapshots are always out of date, latest svn is pretty stable, so one must unmask everything to get the - versions Ok, now you just tossed my little (pee brain) around quite significantly... Your saying that not operator will get me the - (SVN) version of a package?And that this is most likely the most stable because the devs/hacks work on it often? I cheat and just do this: x11-wm/enlightenment * ~* ** But enlightenment is a special case. e17 has never had a release (snapshots that are known to build are not considered releases) and the majority of users simply check out and build the latest commits in svn. The way the ebuilds are versioned, enlightenment- gets you the latest in svn. That's a pretty normal gentoo convention If so then lets put it to the test. Maybee app-arch/xz-utils ? so my entry in /etc/portage/package.keywords should look like this: app-arch/xz-utils Nothing I tried in either package.keywords or package.unmask make the app-arch/xz-utils- (SVN) version available. So what did I miss? You need to put a mask after the package name - *, ~* or **. The default is to use your current ACCEPT_KEYWORDS. * removes masking keywords if the package is stable on your arch ~* removes masking keywords if the package is stable on any arch ** removes masking keywords for the package unconditionally -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: package.keywords
Nikos Chantziaras realnc at arcor.de writes: There's a point to everything. You need to use whatever suits what you want to do. snip Ok got it. Now how do I unmask the version of: app-arch/xz-utils Available versions: ** James
[gentoo-user] Re: package.keywords
Neil Bothwick neil at digimed.co.uk writes: make the app-arch/xz-utils- (SVN) version available. This ebuild doesn't have a valid KEYWORDS line, try something less broken. OK, I tried is because there does not seem to be other dependancies. Pick an example for me, cause nothing I ever do get me a - package variant for install on a stable system. I understand what every one is has written, I just need one example, not an exception like enlightenment OK? James
[gentoo-user] Re: package.keywords
On 06/23/2009 06:28 PM, James wrote: Nikos Chantziarasrealncat arcor.de writes: There's a point to everything. You need to use whatever suits what you want to do. snip Ok got it. Now how do I unmask the version of: app-arch/xz-utils Available versions: ** By putting: app-arch/xz-utils ** in package.keywords. I used that because is the only version available. If you wish narrow it down nonetheless, use: ~app-arch/xz-utils- **
[gentoo-user] Re: package.keywords
Alan McKinnon alan.mckinnon at gmail.com writes: I cheat and just do this: x11-wm/enlightenment * ~* ** Does not work for xz-utils. Neil's post may be the reason, but there is definately nothing I've read (in man pages) to distinguish these anomalous cases? But enlightenment is a special case. e17 has never had a release (snapshots that are known to build are not considered releases) and the majority of users simply check out and build the latest commits in svn. The way the ebuilds are versioned, enlightenment- gets you the latest in svn. That's a pretty normal gentoo convention You need to put a mask after the package name - *, ~* or **. The default is to use your current ACCEPT_KEYWORDS. * removes masking keywords if the package is stable on your arch ~* removes masking keywords if the package is stable on any arch ** removes masking keywords for the package unconditionally none of these worked for the xz-utils package. Can we find a simple example that does work? (not enlightenment).? James
Re: [gentoo-user] Re: package.keywords
On Tuesday 23 June 2009 17:49:40 James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: * removes masking keywords if the package is stable on your arch ~* removes masking keywords if the package is stable on any arch ** removes masking keywords for the package unconditionally none of these worked for the xz-utils package. Can we find a simple example that does work? (not enlightenment).? You want app-arch/xz-utils ** in package.keywords. It is blocked by lzma, but that entry does at least get the emerge past the mask stage: nazgul xz-utils # echo app-arch/xz-utils ~* /etc/portage/package.keywords/temp nazgul xz-utils # emerge -av1 xz-utils These are the packages that would be merged, in order: Calculating dependencies... done! !!! All ebuilds that could satisfy app-arch/xz-utils have been masked. !!! One of the following masked packages is required to complete your request: - app-arch/xz-utils- (masked by: missing keyword) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. nazgul xz-utils # echo app-arch/xz-utils ** /etc/portage/package.keywords/temp nazgul xz-utils # emerge -av1 xz-utils These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N] app-arch/xz-utils- 0 kB [blocks B ] app-arch/lzma-utils (app-arch/lzma-utils is blocking app- arch/xz-utils-) -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: package.keywords
James wireless at tampabay.rr.com writes: 'man portage' does not show the use of the (=) syntax as an example for emerge? Sorry for my sloppiness I should have been more precise (more coffee required). It should have read: 'man portage' does not show the use of the (=) syntax within the package.keywords file ? For package.keywords I do use these symbols: * package is visible if it is stable on any architecture ~* package is visible if it is in testing on any architecture ** package is always visible (KEYWORDS are ignored completely) (and the tilde ~ symbol). but not or = Where do I read more and find more of the latest example for syntax with portage and the different files therein? ??? James
Re: [gentoo-user] Re: package.keywords
On 6/22/09, James wirel...@tampabay.rr.com wrote: Where do I read more and find more of the latest example for syntax with portage and the different files therein? snip / It should have read: 'man portage' does not show the use of the (=) syntax within the package.keywords file ? No, but it instructs one to peek into man 5 ebuild for the info. If you look again at the portage manpage, the section on package.keywords states of the file format: one DEPEND atom per line followed by additional KEYWORDS And at the top (Glossary) it says about these atoms: DEPEND atom A string which matches a package. It is of the form category/package. It may also contain optional logical operators and versions. More reading: ebuild(5) Follow this more reading-hint by entering man 5 ebuild. The resulting manpage tells you quite extensively (even everything?) about the atoms, with many examples, and more. It takes a meticulous, technically inclined (or otherwise anal-retentive? :) ) mind to read these manpage-thingies which were structured and invented before the modern hypertext-intarweb hit the streets two decades ago. And sure, some of them are written badly, but IMHO the gentoo ones are pretty ok from a user's POV. So, as a conclusion, you probably want to use ~ instead of = in there as you apparently are running a mostly stable box (arch) instead of testing (~arch)? -- Arttu V.
[gentoo-user] Re: package.keywords
Arttu V. arttuv69 at gmail.com writes: More reading: ebuild(5) Ah, ok so there is not restriction on using any of the the boolean operators in any config file underneath /etc/portage? as section 5 does not mention any So, as a conclusion, you probably want to use ~ instead of = in there as you apparently are running a mostly stable box (arch) instead of testing (~arch)? This is my (mis)conception, although, as you have suggest, there are (gentoo) cultural norms that do suggest certain boolean operations should not be used, in say for example, package.keywords? I'm mostly running stable with exceptions being enabled via the /etc/portage file structure. Usually it's small, but now with kde4, BLOAT is my modus operandi, not by choice.. thanks, James
Re: [gentoo-user] Re: package.keywords
On Monday 22 June 2009 17:51:31 James wrote: So, as a conclusion, you probably want to use ~ instead of = in there as you apparently are running a mostly stable box (arch) instead of testing (~arch)? This is my (mis)conception, although, as you have suggest, there are (gentoo) cultural norms that do suggest certain boolean operations should not be used, in say for example, package.keywords? That's more just a safeguard against forgetting you put it there than anything else :-) The vast majority of cases will use only the = operator or nothing. That's so you unmask the one version you are interested in, not everything from here on out, including every buggy, pre-release and just plain broken version that happens to have an ebuild. The use-case for no operator is mostly for the case where you run say a stable box, and want the latest of a specific well-known package. You might want the latest Qt for example. Another example is -svn ebuilds - enlightenment is a case in point. The snapshots are always out of date, latest svn is pretty stable, so one must unmask everything to get the - versions -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: package.keywords
On Mon, 22 Jun 2009 15:51:31 + (UTC), James wrote: I'm mostly running stable with exceptions being enabled via the /etc/portage file structure. Usually it's small, but now with kde4, BLOAT is my modus operandi, not by choice.. It's easier to manage if you make portage.keywords a directory then put the actual packages in files within that directory. That way you can separate the files needed to run KDE4 from any other group of packages. All package.* files in /etc/portage can be replaced a directories, then all the files in that directory are considered as a whole. -- Neil Bothwick Therapy is expensive, popping bubble wrap is cheap! You choose. signature.asc Description: PGP signature
Re: [gentoo-user] Re: package.keywords
Neil Bothwick wrote: On Mon, 22 Jun 2009 15:51:31 + (UTC), James wrote: I'm mostly running stable with exceptions being enabled via the /etc/portage file structure. Usually it's small, but now with kde4, BLOAT is my modus operandi, not by choice.. It's easier to manage if you make portage.keywords a directory then put the actual packages in files within that directory. That way you can separate the files needed to run KDE4 from any other group of packages. All package.* files in /etc/portage can be replaced a directories, then all the files in that directory are considered as a whole. For some reason, my light bulb has still not came on so here comes some questions. I would create /etc/portage/package.keywords then inside that another directory or a set of files? Say, one named KDE4 to put all of KDE4 and it's little friends and then another for some other set of packages? Is this sort of like the sets thing which I am still curious about? Right now, package.keywords and friends are files not directories. Maybe tarring up your portage directory and emailing me off list would help? I need a light bulb moment here. :/ Dale :-) :-)
Re: [gentoo-user] Re: package.keywords
On Mon, 22 Jun 2009 18:17:16 -0500, Dale wrote: All package.* files in /etc/portage can be replaced a directories, then all the files in that directory are considered as a whole. For some reason, my light bulb has still not came on so here comes some questions. I would create /etc/portage/package.keywords then inside that another directory or a set of files? A set of files. Say, one named KDE4 to put all of KDE4 and it's little friends and then another for some other set of packages? Exactly. The portage man page explains it well. /etc/portage/ Any file in this directory that begins with package. can be more than just a flat file. If it is a directory, then all the files in that directory will be sorted in ascending alphabetical order by file name and summed together as if it were a single file. Example: /etc/portage/package.keywords/common /etc/portage/package.keywords/e17 /etc/portage/package.keywords/kde Is this sort of like the sets thing which I am still curious about? Not really, it's just an alternative way of organising the package.* data. -- Neil Bothwick Asking whether machines can think is like asking whether submarines can swim. signature.asc Description: PGP signature
Re: [gentoo-user] Re: package.keywords/kde
On Monday 12 December 2005 11:23, a tiny voice compelled Ernie Schroder to write: On Monday 12 December 2005 11:13, a tiny voice compelled Neil Bothwick to write: On Mon, 12 Dec 2005 10:59:20 -0500, Ernie Schroder wrote: This is exactly why you should not use ACCEPT_KEYWORDS on the command line. It applies to the whole emerge process, so even if KDE would be happy with the installed version of the dependencies, you have told emerge to upgrade them. That's why the correct approach is to add the various KDE packages to /etc/portage/package.keywords. So, if I understand what you're saying, using ACCEPT_KEYWORDS on the command line, brings in all dependant packages regardless of they're being needed for the app being merged. Somehow I don't think that's the way it should be Why not? By setting the variable on the command, you have made it global, although temporarily, so it does not only apply to kde. When you emerge a package, portage checks its dependencies too, and they were out of date according to your settings at the time. Setting this on the command line is even more wide-ranging than putting it in /etc/make.conf, because it overrides anything in /etc/portage/package.keywords too. Thanks Neil. I'm nearly clear on this now. A bit more pondering and I'll fully grasp the logic. I do appreciate your patience. So far so good with the downgrades. -- Regards, Ernie 100% Microsoft and Intel free 11:20:16 up 2 days, 2:43, 4 users, load average: 2.34, 2.41, 1.69 Linux 2.6.14-gentoo-r42.6.14-r-4_new i686 AMD Athlon(tm) XP 2400+ The downgrades went pretty well. They broke mplayer and I suppose anything else that uses libdirectfb, but Remerging mplayer has fixed that. No more odd behaviour from Portage. Thanks all. -- Regards, Ernie 100% Microsoft and Intel free 09:41:45 up 3 days, 1:05, 4 users, load average: 0.03, 0.32, 0.57 Linux 2.6.14-gentoo-r42.6.14-r-4_new i686 AMD Athlon(tm) XP 2400+ -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: package.keywords/kde
Ernie Schroder [EMAIL PROTECTED] wrote: [ebuild UD] sys-devel/m4-1.4.3 [1.4.4] [ebuild UD] sys-devel/autoconf-wrapper-3-r1 [3.2] [nomerge ] app-admin/perl-cleaner-1.01 [ebuild UD] dev-lang/perl-5.8.6-r8 [5.8.7-r2] [ebuild UD]sys-devel/libperl-5.8.6-r1 [5.8.7] The four packages above that portage wants to downgrade are all in ~x86. Looks like you had ACCEPT_KEYWORDS=~x86 in your /etc/make.conf but deleted it or you removed the packages from package.keywords. Hope that helps, Marc -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: package.keywords/kde
On Monday 12 December 2005 09:12, a tiny voice compelled Marc Christiansen to write: Ernie Schroder [EMAIL PROTECTED] wrote: [ebuild UD] sys-devel/m4-1.4.3 [1.4.4] [ebuild UD] sys-devel/autoconf-wrapper-3-r1 [3.2] [nomerge ] app-admin/perl-cleaner-1.01 [ebuild UD] dev-lang/perl-5.8.6-r8 [5.8.7-r2] [ebuild UD]sys-devel/libperl-5.8.6-r1 [5.8.7] The four packages above that portage wants to downgrade are all in ~x86. Looks like you had ACCEPT_KEYWORDS=~x86 in your /etc/make.conf but deleted it or you removed the packages from package.keywords. Hope that helps, Marc Close but no cigar. I did use ACCEPT_KEYWORDS=~x86 emerge kde All of these ~x86 packages were brought in at that time I'm about at the point where I'll let portage downgrade everything it wants to, but I'm afraid that it might break something else. I did try: ACCEPT_KEYWORDS=~x86 emerge-p world and there are MANY more packages in that list, so I'm sure they came in with KDE-3.5 from emerge .log: 1133846721: Started emerge on: Dec 06, 2005 00:25:21 1133846721: *** emerge --update --ask kde 1133846729: emerge (1 of 122) sys-devel/patch-2.5.9-r1 to / 1133846729: === (1 of 122) Cleaning snip 1133851691: emerge (14 of 122) sys-devel/libperl-5.8.7 to / 1133851691: === (14 of 122) snip 1133852294: emerge (16 of 122) sys-devel/autoconf-wrapper-3.2 to / 1133852294: === (16 of 122) snip m4 is in the log in the same build date, as are all others I checked. Frankly I'm baffled. - Regards, Ernie 100% Microsoft and Intel free 09:22:53 up 2 days, 46 min, 2 users, load average: 0.18, 0.09, 0.12 Linux 2.6.14-gentoo-r42.6.14-r-4_new i686 AMD Athlon(tm) XP 2400+ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: package.keywords/kde
Ernie Schroder schreef: On Monday 12 December 2005 09:12, a tiny voice compelled Marc Christiansen to write: Ernie Schroder [EMAIL PROTECTED] wrote: [ebuild UD] sys-devel/m4-1.4.3 [1.4.4] [ebuild UD] sys-devel/autoconf-wrapper-3-r1 [3.2] [nomerge ] app-admin/perl-cleaner-1.01 [ebuild UD] dev-lang/perl-5.8.6-r8 [5.8.7-r2] [ebuild UD] sys-devel/libperl-5.8.6-r1 [5.8.7] The four packages above that portage wants to downgrade are all in ~x86. Looks like you had ACCEPT_KEYWORDS=~x86 in your /etc/make.conf but deleted it or you removed the packages from package.keywords. Hope that helps, Marc Close but no cigar. I did use ACCEPT_KEYWORDS=~x86 emerge kde All of these ~x86 packages were brought in at that time Well, that explains it. For the 7 billionth time, ACCEPT_KEYWORDS= on the emerge command line is a /temporary/ setting, valid /only for that emerge/. Portage *does not remember it* once the emerge is completed-- so as far as it knows, it is only allowed to install the stable packages for KDE, not the unstable. That is why it's trying to downgrade-- and this is why you are not supposed to use ACCEPT_KEYWORDS= on the command line (because this will happen, and it's a real PITA, as you see). In order to authorize Portage to accept *and keep* the unstable packages, you /must/ 1) either add ~x86 to the ACCEPT_KEYWORDS= setting in /etc/make.conf (but this will allow all unstable packages, which you may not want); 2) add the specific unstable packages you want to /etc/portage/package.keywords These are the only settings that will permanently override the default settings, which are allow stable only, unsurprisingly. I'm sorry to say, but either suck it up and add all the relevant packages to /etc/portage/package.keywords (several people have posted little scripts to do this, check the archives), or suck it up and wait till the packages are stable. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: package.keywords/kde
On Mon, 12 Dec 2005 09:50:17 -0500, Ernie Schroder wrote: ACCEPT_KEYWORDS=~x86 emerge kde All of these ~x86 packages were brought in at that time This is exactly why you should not use ACCEPT_KEYWORDS on the command line. It applies to the whole emerge process, so even if KDE would be happy with the installed version of the dependencies, you have told emerge to upgrade them. That's why the correct approach is to add the various KDE packages to /etc/portage/package.keywords. I'm about at the point where I'll let portage downgrade everything it wants to, but I'm afraid that it might break something else. That's unlikely, if so, emerge would complain about a dependency of KDE being unavailable. The worst that can happen is that part of KDE could stop working, possibly preventing you loading the desktop. In which case, emerge -uav world will tell you which package is needed but unavailable because of masking, so you can add it to /etc/portage/package.keywords. -- Neil Bothwick Guns don't kill people--it's those little pieces of lead. signature.asc Description: PGP signature
Re: [gentoo-user] Re: package.keywords/kde
On Monday 12 December 2005 10:11, a tiny voice compelled Holly Bostick to write: Ernie Schroder schreef: On Monday 12 December 2005 09:12, a tiny voice compelled Marc Christiansen to write: Ernie Schroder [EMAIL PROTECTED] wrote: [ebuild UD] sys-devel/m4-1.4.3 [1.4.4] [ebuild UD] sys-devel/autoconf-wrapper-3-r1 [3.2] [nomerge ] app-admin/perl-cleaner-1.01 [ebuild UD] dev-lang/perl-5.8.6-r8 [5.8.7-r2] [ebuild UD] sys-devel/libperl-5.8.6-r1 [5.8.7] The four packages above that portage wants to downgrade are all in ~x86. Looks like you had ACCEPT_KEYWORDS=~x86 in your /etc/make.conf but deleted it or you removed the packages from package.keywords. Hope that helps, Marc Close but no cigar. I did use ACCEPT_KEYWORDS=~x86 emerge kde All of these ~x86 packages were brought in at that time Well, that explains it. For the 7 billionth time, ACCEPT_KEYWORDS= on the emerge command line is a /temporary/ setting, valid /only for that emerge/. Portage *does not remember it* once the emerge is completed-- so as far as it knows, it is only allowed to install the stable packages for KDE, not the unstable. That is why it's trying to downgrade-- and this is why you are not supposed to use ACCEPT_KEYWORDS= on the command line (because this will happen, and it's a real PITA, as you see). In order to authorize Portage to accept *and keep* the unstable packages, you /must/ 1) either add ~x86 to the ACCEPT_KEYWORDS= setting in /etc/make.conf (but this will allow all unstable packages, which you may not want); 2) add the specific unstable packages you want to /etc/portage/package.keywords These are the only settings that will permanently override the default settings, which are allow stable only, unsurprisingly. I'm sorry to say, but either suck it up and add all the relevant packages to /etc/portage/package.keywords (several people have posted little scripts to do this, check the archives), or suck it up and wait till the packages are stable. HTH, Holly I'm not sure I follow your logic Holly. I know exactly what ACCEPT_KEYWORDS on the command line does. I used it for KDE only and all of the kde packages are in package.keywords. One would think that an update would not try to downgrade packages that are depended on by entries in .keywords, or is portage just not that smart? Assuming that I DO NOT KNOW WHAT I'M TALKING ABOUT, in your opinion, would it be safe to let portage downgrade the packages it seems to want to? (several people have posted little scripts to do this, check the archives) That is how I generated package.keywords. The packages that are trying to downgrade were not listed by those scripts. -- Regards, Ernie 100% Microsoft and Intel free 10:35:12 up 2 days, 1:58, 2 users, load average: 0.02, 0.15, 0.27 Linux 2.6.14-gentoo-r42.6.14-r-4_new i686 AMD Athlon(tm) XP 2400+ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: package.keywords/kde
On Mon, 12 Dec 2005 10:59:20 -0500, Ernie Schroder wrote: This is exactly why you should not use ACCEPT_KEYWORDS on the command line. It applies to the whole emerge process, so even if KDE would be happy with the installed version of the dependencies, you have told emerge to upgrade them. That's why the correct approach is to add the various KDE packages to /etc/portage/package.keywords. So, if I understand what you're saying, using ACCEPT_KEYWORDS on the command line, brings in all dependant packages regardless of they're being needed for the app being merged. Somehow I don't think that's the way it should be Why not? By setting the variable on the command, you have made it global, although temporarily, so it does not only apply to kde. When you emerge a package, portage checks its dependencies too, and they were out of date according to your settings at the time. Setting this on the command line is even more wide-ranging than putting it in /etc/make.conf, because it overrides anything in /etc/portage/package.keywords too. -- Neil Bothwick PC DOS Error #03: Windows not found: (C)heer (P)arty (D)ance signature.asc Description: PGP signature
Re: [gentoo-user] Re: package.keywords/kde
On Monday 12 December 2005 11:13, a tiny voice compelled Neil Bothwick to write: On Mon, 12 Dec 2005 10:59:20 -0500, Ernie Schroder wrote: This is exactly why you should not use ACCEPT_KEYWORDS on the command line. It applies to the whole emerge process, so even if KDE would be happy with the installed version of the dependencies, you have told emerge to upgrade them. That's why the correct approach is to add the various KDE packages to /etc/portage/package.keywords. So, if I understand what you're saying, using ACCEPT_KEYWORDS on the command line, brings in all dependant packages regardless of they're being needed for the app being merged. Somehow I don't think that's the way it should be Why not? By setting the variable on the command, you have made it global, although temporarily, so it does not only apply to kde. When you emerge a package, portage checks its dependencies too, and they were out of date according to your settings at the time. Setting this on the command line is even more wide-ranging than putting it in /etc/make.conf, because it overrides anything in /etc/portage/package.keywords too. Thanks Neil. I'm nearly clear on this now. A bit more pondering and I'll fully grasp the logic. I do appreciate your patience. So far so good with the downgrades. -- Regards, Ernie 100% Microsoft and Intel free 11:20:16 up 2 days, 2:43, 4 users, load average: 2.34, 2.41, 1.69 Linux 2.6.14-gentoo-r42.6.14-r-4_new i686 AMD Athlon(tm) XP 2400+ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: package.keywords/kde
Ernie Schroder schreef: On Monday 12 December 2005 10:11, a tiny voice compelled Holly Bostick to write: Ernie Schroder [EMAIL PROTECTED] wrote: [ebuild UD] sys-devel/m4-1.4.3 [1.4.4] [ebuild UD] sys-devel/autoconf-wrapper-3-r1 [3.2] [nomerge ] app-admin/perl-cleaner-1.01 [ebuild UD] dev-lang/perl-5.8.6-r8 [5.8.7-r2] [ebuild UD] sys-devel/libperl-5.8.6-r1 [5.8.7] Close but no cigar. I did use ACCEPT_KEYWORDS=~x86 emerge kde All of these ~x86 packages were brought in at that time Well, that explains it. For the 7 billionth time, ACCEPT_KEYWORDS= on the emerge command line is a /temporary/ setting, valid /only for that emerge/. Portage *does not remember it* once the emerge is completed-- so as far as it knows, it is only allowed to install the stable packages for KDE, not the unstable. That is why it's trying to downgrade-- and this is why you are not supposed to use ACCEPT_KEYWORDS= on the command line (because this will happen, and it's a real PITA, as you see). I'm not sure I follow your logic Holly. I know exactly what ACCEPT_KEYWORDS on the command line does. I used it for KDE only and all of the kde packages are in package.keywords. One would think that an update would not try to downgrade packages that are depended on by entries in .keywords, or is portage just not that smart? But what about everything else? According to you, you did ACCEPT_KEYWORDS=~x86 emerge kde The thing is, you've basically done an export variable operation. An exported variable is valid across the entire session. It does not persist across sessions, but it persists for all processes performed in that shell session. So basically every emerge you did until you started a new login shell used ~x86 rather than x86. The direct dependencies of this package of kde are: Runtime Dependencies kde-3.5.0 kde-base/kdeaddons3.5.0 kde-base/kdeadmin3.5.0 kde-base/kdeartwork3.5.0 kde-base/kdebase3.5.0 kde-base/kdeedu3.5.0 kde-base/kdegames3.5.0 kde-base/kdegraphics3.5.0 kde-base/kdelibs3.5.0 kde-base/kdemultimedia3.5.0 kde-base/kdenetwork3.5.0 kde-base/kdepim3.5.0 kde-base/kdetoys3.5.0 kde-base/kdeutils3.5.0 kde-base/kdewebdev3.5.0 accessibility kde-base/kdeaccessibility3.5.0 which you've said you have in /etc/package.keywords. Fine. However, the deep dependencies are not, but were upgraded by the use of ACCEPT_KEYWORDS on the command line, as Neil said: Neil Bothwick schreef: This is exactly why you should not use ACCEPT_KEYWORDS on the command line. It applies to the whole emerge process, so even if KDE would be happy with the installed version of the dependencies, you have told emerge to upgrade them. So, looking for perl-related deep dependencies, we find: Runtime Dependencies kdenetwork-3.5.0 dev-lang/perl snip of the others So-- kdenetwork depends on perl directly, and the kde metapackage you've installed depends on kdenetwork. So perl is a deep dependency of (the particular) kde (metapackage) you have installed. Therefore it was upgraded *temporarily* by your use of ACCEPT_KEYWORDS on the command line (because an update became available due to the command line option). Libperl also upgraded by this procedure as perl depends on libperl. Runtime Dependencies perl-5.8.7-r3 = sys-devel/libperl - 5.8.7 berkdb sys-libs/db gdbm = sys-libs/gdbm - 1.8.3 So you have upgraded libperl and perl to ~x86 by using ACCEPT_KEYWORDS on the command line. But that doesn't really explain autoconf-wrapper, or m4, for example. Did you perhaps do some further emerges that upgraded autoconf or autoconf wrapper, m4, and perl-cleaner? Perhaps emerge -u world after the emerge kde? That would have upgraded packages that depend on the upgraded packages (perl-cleaner of course depends on perl; autoconf-wrapper depends on autoconf, which depends on perl and has an upgrade to ~x86; m4 depends on autoconf-wrapper). In any case, some time must have passed and you logged off, shut down, or in some other way you must have closed the current login session in the term and begun another, which used the 'regular' settings read from /etc/make.conf and /etc/portage/package.keywords, since as soon as you did an emerge -u world in what must have been a new session, Portage saw that a number of packages were not authorized, because it has forgotten the exported settings from the last session. So the affected packages emerged during the export must be downgraded to stable. HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: package.keywords/kde
On Monday 12 December 2005 12:28, a tiny voice compelled Holly Bostick to write: In any case, some time must have passed and you logged off, shut down, or in some other way you must have closed the current login session in the term and begun another, which used the 'regular' settings read from /etc/make.conf and /etc/portage/package.keywords, since as soon as you did an emerge -u world in what must have been a new session, Portage saw that a number of packages were not authorized, because it has forgotten the exported settings from the last session. Probably what happened. Thanks for clearing that up. I really do appreciate the time you took to explain So the affected packages emerged during the export must be downgraded to stable. Doing so now. -- Regards, Ernie 100% Microsoft and Intel free 13:22:25 up 2 days, 4:46, 4 users, load average: 2.39, 2.89, 2.83 Linux 2.6.14-gentoo-r42.6.14-r-4_new i686 AMD Athlon(tm) XP 2400+ -- gentoo-user@gentoo.org mailing list
