[gentoo-dev] glep-42-news: sparc multilib profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since yesterday we finally have a stable version of app-admin/eselect-news in the tree [0], now it's time to get some news rollin' :) The 2008.0 sparc profile uses a pure 32 bit userland and a 64 bit kernel. A few days ago I added an experimental multilib profile which uses 32 bit as default but also supports -m64. Problem is you can't simply switch your make.profile symlink, that's why we have a migration guide [1] and the purpose of this news item would be to notify users who switched to that profile that they need to read and follow that guide. Besides causing gcc and glibc to fail compilation, not reading that guide would also make a users system end up with two different libdirs: lib and lib32 (All our non-multilib profile use lib as libdir and our multilib profiles use lib32/lib64 with lib as a symlink to one of them) I'll commit this in 72 hours unless someone objects. Regards, Friedrich [0] https://bugs.gentoo.org/show_bug.cgi?id=251810 [1] http://dev.gentoo.org/~bluebird/sparc-multilib/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklaKmMACgkQknxn9PmJ76Uk/QCfUrvvCaWo+qAXHXBA+DqxrkrB 04wAoJlOYZ5+K5xS+JjbALkcDYP93Ve3 =+aPC -END PGP SIGNATURE- Title: Migrating to the new sparc mutlilib profile Author: Friedrich Oslage blueb...@gentoo.org Content-Type: text/plain Posted: 2008-12-30 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default/linux/sparc/experimental/multilib Display-If-Profile: default/linux/sparc/experimental/multilib/desktop Display-If-Profile: default/linux/sparc/experimental/multilib/developer Display-If-Profile: default/linux/sparc/experimental/multilib/server When migrating to the new sparc mutlilib profile please keep in mind that it is still in an experimental state. Also note that you need to follow the migration guide [0], otherwise important packages such as gcc or glibc will fail to compile and most other packages will be installed incorrectly. [0] http://dev.gentoo.org/~bluebird/sparc-multilib/ 2008-12-30-sparc-multilib.en.txt.sig Description: Binary data
Re: [gentoo-dev] glep-42-news: sparc multilib profile
On Tue, Dec 30, 2008 at 8:04 AM, Friedrich Oslage blueb...@gentoo.org wrote: [1] http://dev.gentoo.org/~bluebird/sparc-multilib/ I would put it in the gentoo.org/doc/en/ domain and link to it in the gentoo-sparc index (http://www.gentoo.org/proj/en/base/sparc/index.xml) 2 cents, Jeremy
Re: [gentoo-dev] glep-42-news: sparc multilib profile
Jeremy Olexa wrote: On Tue, Dec 30, 2008 at 8:04 AM, Friedrich Oslage blueb...@gentoo.org wrote: [1] http://dev.gentoo.org/~bluebird/sparc-multilib/ I would put it in the gentoo.org/doc/en/ domain and link to it in the gentoo-sparc index (http://www.gentoo.org/proj/en/base/sparc/index.xml) 2 cents, Jeremy Mmm, not so much. Documentation like this, that's so specific to one particular architecture, would be better off in project documentation -- that's (partly) why ya'll have project directories in the first place. Otherwise it becomes a maintenance burden for the GDP. It'll be easier on the Sparc team to maintain it if it's in their own /proj/ space. What we can do, however, is list it in metadoc.xml, so that it will show up in /doc/en/list.xml. signature.asc Description: OpenPGP digital signature
[gentoo-dev] reorganization of /var/lib gentoo-related files
I'm proposing to reorganize the files related to Gentoo inside /var/lib. Currently we have this situation (at least on my system): /var/lib/eselect /var/lib/gentoo/enews /var/lib/herdstat/ /var/lib/module-rebuild /var/lib/portage The main dir should be something like /var/lib/gentoo, so I'd see all gentoo-related files as /var/lib/gentoo/eselect /var/lib/gentoo/enews /var/lib/gentoo/herdstat/ /var/lib/gentoo/module-rebuild /var/lib/gentoo/portage What do you think about? Regards, Fabio
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Wed, 31 Dec 2008 01:12:23 +0100 Fabio Rossi ross...@inwind.it wrote: I'm proposing to reorganize the files related to Gentoo inside /var/lib. Currently we have this situation (at least on my system): /var/lib/eselect /var/lib/gentoo/enews /var/lib/herdstat/ /var/lib/module-rebuild /var/lib/portage The main dir should be something like /var/lib/gentoo, so I'd see all gentoo-related files as /var/lib/gentoo/eselect /var/lib/gentoo/enews /var/lib/gentoo/herdstat/ /var/lib/gentoo/module-rebuild /var/lib/gentoo/portage What do you think about? Any reason for that? Aesthetics aren't a very compelling argument IMO, and the FHS also seems to favor the current layout (in my interpretation at least, as we're not really talking about inter-related applications in technical terms). Marius
RE: [gentoo-dev] reorganization of /var/lib gentoo-related files
Hi, this possible reorganization will impact how many packages and which one ? Thanks :P Date: Wed, 31 Dec 2008 03:31:12 +0100 From: gen...@gentoo.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] reorganization of /var/lib gentoo-related files On Wed, 31 Dec 2008 01:12:23 +0100 Fabio Rossi ross...@inwind.it wrote: I'm proposing to reorganize the files related to Gentoo inside /var/lib. Currently we have this situation (at least on my system): /var/lib/eselect /var/lib/gentoo/enews /var/lib/herdstat/ /var/lib/module-rebuild /var/lib/portage The main dir should be something like /var/lib/gentoo, so I'd see all gentoo-related files as /var/lib/gentoo/eselect /var/lib/gentoo/enews /var/lib/gentoo/herdstat/ /var/lib/gentoo/module-rebuild /var/lib/gentoo/portage What do you think about? Any reason for that? Aesthetics aren't a very compelling argument IMO, and the FHS also seems to favor the current layout (in my interpretation at least, as we're not really talking about inter-related applications in technical terms). Marius _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/events.aspx
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
081231 Fabio Rossi wrote: I'm proposing to reorganize the files related to Gentoo inside /var/lib. Currently we have this situation (at least on my system): /var/lib/eselect -- here /var/lib/gentoo/enews /var/lib/herdstat/ /var/lib/module-rebuild -- here /var/lib/portage -- here The main dir should be something like /var/lib/gentoo , so I'd see all gentoo-related files as /var/lib/gentoo/eselect /var/lib/gentoo/enews /var/lib/gentoo/herdstat/ /var/lib/gentoo/module-rebuild /var/lib/gentoo/portage What do you think about? It looks neater simpler to understand in the long run, provided it doesn't break anyone's system in the short run. BTW I have only the 3 entries I have marked above. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-dev] Re: reorganization of /var/lib gentoo-related files
Fabio Rossi ross...@inwind.it posted 200812310112.24019.ross...@inwind.it, excerpted below, on Wed, 31 Dec 2008 01:12:23 +0100: I'm proposing to reorganize the files related to Gentoo inside /var/lib. Currently we have this situation (at least on my system): /var/lib/eselect /var/lib/gentoo/enews /var/lib/herdstat/ /var/lib/module-rebuild /var/lib/portage The main dir should be something like /var/lib/gentoo [...] Except that... in theory, some or all of those apps could technically be used on/for other distributions and platforms as well. Few/none of the other apps, regardless of which distribution they started on, are in directories based on distribution name, I don't believe it fits FHS (as genone pointed out), and while there may be reasons to break standards on occasion, they need to be pretty good to justify the hassle and confusion, and frankly, I just don't see this as being that good. Portage is certainly a candidate for other distributions/platforms, and eselect and genkernel (I guess that's what owns module-rebuild?) could be as well, particularly on Gentoo based distributions. Herdstat doesn't appear to be in the Gentoo tree any longer, so that can be eliminated from the list. Even the one that's currently under gentoo, enews, arguably doesn't belong there, since I see files from other overlays there, and some overlays are independent and may be in fact ultimately targeted primarily at distributions other than Gentoo. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman