[gentoo-dev] Re: On hosting self-produced distfiles
Hi, Mike Frysinger vap...@gentoo.org: first off, drop the caps crap. second, while *you* might be aware of a long history, you provided absolutely none in your first e-mail. thus it completely looked like only 1 person (you) was making a decision which had not been discussed with anyone else. and having recently been placed into QA lead, you decided to use that position to force everyone else to agree. again, without any discussion. So now that all misunderstandings are cleared out and everybody agrees that there was a failure in communication (both on sending and receiving end), we can go on committing awesome stuff to the tree. Thanks. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Sat, Jan 22, 2011 at 04:38:49AM +0200, Theo Chatzimichos wrote: Assuming we're going to move the git.overlays.gentoo.org repos there as well in the near future, this is the structure i am proposing: Yes, they will be merging, but not for many months. What _DO_ need, is getting the namespaces to be identical as soon as possible, and preventing namespace collisions for anything that gets added. Two overall comments about your proposal. 1. We EXPLICITLY need a location for private repositories. - infra: for critical system data [1] - foundation: for legal tracking, personal, financial information - PR project: I don't know what they have in there. I've never looked at their private repo. The current breakdown of private repos: Infra: 2 Foundation: 0, but 2 requested PR: 1 source - portage-main.git - portage-history.git infra (or sysadmin) - (repo1).git - (repo2).git - ... - I don't think that infra should be a toplevel here. As much as we intend to use repos, this is pollution of the namespace. overlay - project (instead of proj) - sunrise.git - kde.git - ... - personal (merge dev/ user/) - aballier.git - alexxy.git - ... - Some of the developer+user repos are NOT overlays, but Gentoo-specific code/applications. - On one hand, I would like user repositories to have a separate namespace, so that other users realize a given repo is NOT from a developer. - On the other side, what do we do when a user with a repo becomes a developer (and when they retire?) website - blogs.git - planet.git - forums.git - gstats.git - packages.git - www.git (the gentoo cvs repo) - ... These are projects, why not include them there? project (includes SOC projects, forks, gentoo projects etc) - devmanual.git - portage.git - ... devmanual IS a website... How are you differentiating project vs. website? [1] We intend on having public infra repos as well, and just having the fewest private repos. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[gentoo-dev] Re: Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Fri, 21 Jan 2011 22:20:27 -0600 Donnie Berkholz dberkh...@gentoo.org wrote: I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. In the same vein, there's no good reason I can think of to discriminate between overlays that are project vs personal, since either can be supported or unsupported. Readability? It's already hard to find the repo you're looking for in that huge list. I wouldn't want to see them mixed. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Fri, 21 Jan 2011 22:20:27 -0600 Donnie Berkholz dberkh...@gentoo.org wrote: I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. Yeah, that'd be a good idea for the concept of repositories. - repos/project/gentoo.git - repos/project/sunrise.git etc. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Saturday 22 January 2011 10:55:19 Robin H. Johnson wrote: 1. We EXPLICITLY need a location for private repositories. didn't know that, so i guess the private dir should be: private - infra - (infrapriv1).git - (infrapriv2).git - foundation - (foundpriv1).git - (foundpriv2).git - pr - - Some of the developer+user repos are NOT overlays, but Gentoo-specific code/applications. These DON'T belong here, they should go to project/ - On one hand, I would like user repositories to have a separate namespace, so that other users realize a given repo is NOT from a developer. - On the other side, what do we do when a user with a repo becomes a developer (and when they retire?) Well, the distinction for unofficial/official overlays happen mostly in layman -L, I don't think users pay attention to our git repo list. Furthermore, I got at least three requests from developers to move their repo from user/ to dev/ (same problem when devs retired). This distinction doesn't make any sense. These are projects, why not include them there? All of the above are *.gentoo.org subdomains project (includes SOC projects, forks, gentoo projects etc) - devmanual.git - portage.git - ... devmanual IS a website... How are you differentiating project vs. website? devmanual should go to website/, you are right. In project/ belongs anything that is not a *.g.o subdomain, and is not an overlay (SOC projects, upstream projects (portage, gorg, rbot*, znurt), forks (gitolite-gentoo)) [1] We intend on having public infra repos as well, and just having the fewest private repos. Send them to project/ as well ;) -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Saturday 22 January 2011 06:20:27 Donnie Berkholz wrote: I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. In the same vein, there's no good reason I can think of to discriminate between overlays that are project vs personal, since either can be supported or unsupported. And I don't see a reason to merge the huge overlays list with the official gentoo tree. They are totally different things, and a future alternative to viewvc in sources.gentoo.org (maybe trac-git) should reflect that. If we show a huge list with ebuild repos to public (especially to new to gentoo) without separating the official tree (including user/unofficial/bad-shaped ones), I suppose we'll give the impression we are like debian, where the user needs the multimedia overlay to get multimedia ebuilds, or the kde overlay to install kde. For the second part of your question, Ryan's responce is perfect. -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
Hi all! Why not use redmine as sources.gentoo.org? 2011/1/22 Theo Chatzimichos tampak...@gentoo.org: On Saturday 22 January 2011 06:20:27 Donnie Berkholz wrote: I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. In the same vein, there's no good reason I can think of to discriminate between overlays that are project vs personal, since either can be supported or unsupported. And I don't see a reason to merge the huge overlays list with the official gentoo tree. They are totally different things, and a future alternative to viewvc in sources.gentoo.org (maybe trac-git) should reflect that. If we show a huge list with ebuild repos to public (especially to new to gentoo) without separating the official tree (including user/unofficial/bad-shaped ones), I suppose we'll give the impression we are like debian, where the user needs the multimedia overlay to get multimedia ebuilds, or the kde overlay to install kde. For the second part of your question, Ryan's responce is perfect. -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-01-2011 03:20, Donnie Berkholz wrote: On 04:38 Sat 22 Jan , Theo Chatzimichos wrote: Assuming we're going to move the git.overlays.gentoo.org repos there as well in the near future, this is the structure i am proposing: source - portage-main.git - portage-history.git ... overlay - project (instead of proj) - sunrise.git - kde.git - ... - personal (merge dev/ user/) - aballier.git - alexxy.git - ... I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. In the same vein, there's no good reason I can think of to discriminate between overlays that are project vs personal, since either can be supported or unsupported. I think a distinction between tree and project overlays can be useful in case we ever consider splitting the main tree. In that case, our new tree would be composed of all the split repos under tree and users would have an easy way to distinguish between the tree and project overlays. We could even provide the ability for users to have just some of the split repos and thus not require the complete tree. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNOvOLAAoJEC8ZTXQF1qEP924P/2dbxlK8m3y0k4/ArQojeJH7 9HY3NzMImIuIW44kcdGhEj6+bJDEPGTz1Pb1zGrNMSxNYgrxrXYkEKEWldNYszm7 TNqQvm+Pl9D39ckjjDzV+zMfKZQn9UtM3MCTOw4ozWZynSLGajkpZK6Cp4BIiOjF JiPi+Q8zSw/Xc8umLxK4ZfWy4n4WhLDbJgxO8ws+s27iSlQemJhqlOmCw1nMAcyB FPlf1cyMa0MxUStqHWzJ0MBtYOfkxoSNvnXAoVl47DGPbOagdSSWkbbmx5p6vn2C HpJ/xNfJkDoPa6DPrbBdQtmiay3A72fkokwLSFKMvNhMjDMeMhR30IPxDkrRf/ls faIK7FKeJbh/sWr0XgBVR5rsASSQkor647DbjT04/v+g9HN/bB9IxmYY9hVC66aw +j0gph07zTuXUAHDcqqSnMxlr3MGril+mAVXf+ne2N6emrP88K2plnSGc5LmUfyy i+eEfb5UBTxfBfmyollKArVS9djzKveKLiVgIn1ga6kyj7JGYiDZnJTOfHJ1sfdc R8dti5qyqQUruzmjkEeGQEMBpawIh/ZYY3LDfh7MaDkLjLScdVUHgZDipn+QjIUx lliDjRK5sa1S4WWojK0t/gd3ikW/YrXQRHpLo9EOtMzkRfR9FSbFv+ew8ud5RlyN eIQrF7smR0LCOMF1/mzj =ytaq -END PGP SIGNATURE-
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Saturday 22 January 2011 16:58:38 Alexey Shvetsov wrote: Hi all! Why not use redmine as sources.gentoo.org? idl0r installed trac-git for git.overlays, it needs some testing before starting to redesign the overlays webpages (ETA 1 month due to my exams) If we decide that it doesn't suit our needs we'll proceed in trying something else, but this is totally offtopic, please stick to the topic. -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22-01-2011 11:32, Theo Chatzimichos wrote: On Saturday 22 January 2011 10:55:19 Robin H. Johnson wrote: 1. We EXPLICITLY need a location for private repositories. didn't know that, so i guess the private dir should be: private - infra - (infrapriv1).git - (infrapriv2).git - foundation - (foundpriv1).git - (foundpriv2).git - pr - - Some of the developer+user repos are NOT overlays, but Gentoo-specific code/applications. These DON'T belong here, they should go to project/ Why not provide a tree for overlays and another for application repositories? - On one hand, I would like user repositories to have a separate namespace, so that other users realize a given repo is NOT from a developer. - On the other side, what do we do when a user with a repo becomes a developer (and when they retire?) Well, the distinction for unofficial/official overlays happen mostly in layman -L, I don't think users pay attention to our git repo list. Furthermore, I got at least three requests from developers to move their repo from user/ to dev/ (same problem when devs retired). This distinction doesn't make any sense. Instead of relying on the name space for such a distinction, I propose we use a label for that. Preferably we should have an automatic system to produce the label and have it present on any online repo browsers (gitweb?) and on project management apps (redmine?) so that users have no doubt when looking at projects.gentoo.org / overlays.gentoo.org about the type of a repo. The label to distinguish between developers and non-developers repos could take advantage of the ldap info. We could also use labels for the status of a project like we're already doing on layman. With the above in mind and some of the suggestions in the other emails, what about the following structure: tree - core-portage-tree.git - core-portage-historical-tree.git (possibly some day) - gnome.git - kde.git - sci.git - x11.git (split profiles, keywords(?)) - profiles.git overlay - project (do we want to support non-gentoo projects?) . gnome.git . kde.git . sci.git . sunrise.git . external project a* . ... - individual (we need to decide whether we want to host and the legal costs of hosting non-gentoo individual's or project's repos) . aballier.git . alexxy.git . user a* . ... project - pages (project web pages, but not applications code source like forums, blogs or PMS) . main-site.git (split from the current gentoo repo) . gentoo-project.git (should we split the current gentoo repo?) . devmanual.git - repositories . project (tied to projects) ^ gentoo-forums.git ^ gentoo-blogs.git ^ gitolite-gentoo ^ gstats.git ^ packages.git ^ planet.git ^ portage.git ^ pms.git ^ releng.git . individual (work of one or more individuals not tied to any projects) ^ portage-utils.git (not tied to any project afaik) ^ layman.git ^ rbot-gentoo (is it tied to any project?) ^ cool new toy for Gentoo done by devs A and B ^ soc (include individual soc projects here) (would it make sense to organize by year?) ' soc project 1 ' soc project 2 private - foundation . legal . finances . ... - infra . infra 1 . infra 2 . ... - pr . pr 1 . pr 2 . ... This design includes 4 top-level labels: tree, overlay, project and private: * the tree sub-tree should be used for the Portage tree, it's history and any future trees we choose to have. * the overlay sub-tree should be used to host repositories to be used as overlays. * the project sub-tree should be used to host the web pages and sites and all the repositories for applications / tools. * the private sub-tree should be used for private repositories that cannot be exposed to the public. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNOv+zAAoJEC8ZTXQF1qEPp9EP/AvFRbVsYQHcik4PMMFdwHPO 3vCXl2M0JENah/HBIM7cMigt1KWmk8jPJ4QOdARnFb2rVy9nDbycIzKYhHotg/aO Bh7euJdLj1jxI3DKz1kZCj++DXQyZ0clzBde/c+sYWfw/1bGruRuZoAqr5Tbtkd4 4h6YV2bCHgeJUjUpC/7+K6M1/UNW7MwhdJC9cViLXyZ+O04fGSNZ5g/V7CCQtrE4 oMDodPgmfjwdmp9AqsA6ejVswkhuMbL8KyHS3kEBQXABugQpGnwVnY48KI2oi0yv 4oqa6cv+A6F9hoSrfHk9dytMdegAHtuFmq/70nnLBwVvljrdyGackAJj51oAtLgW 6tZDOGp6ZsjzsruSS3Keh4V2wFRz7Uejjkhkn/QuYMO86QyX3QA0eN9dce/HuOEv zpbgZf3qvVvZ/zFnJw48sYNogfeb+CSQqs1pqRCjLwhShg1TcrBYYldiRvhxKNXl SNBBUQDKSiorLGLnM6T23QEH/hEoVVjH6Z6D/09F0MODpwdv0H+iMJkUIGg1iv7G WladznFgBg/gHjLB15Aq0Ux7eGwd6uoJ1Mm3zt0KbuO14udYgAbW6JvLw2JF7DSV Y5njptBYPTUHx7Oj15LtzrN6RUQMnN/fLM8/VoBVrSb5dnXIdYWwCerL3JzkFsiH
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Saturday 22 January 2011 18:02:59 Jorge Manuel B. S. Vicetto wrote: Why not provide a tree for overlays and another for application repositories? You just repeated my proposal, with the only difference I splitted project from website :P -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] On hosting self-produced distfiles
Hi Diego, I need a clarification on something. On Thu, Jan 20, 2011 at 01:50:35AM +0100, Diego Elio Petten? wrote: If you produced the file yourself, and it doesn't matter if the file is reproducible (unless it is reproducible to sha512 identity), please use the public_html directory in your dev.gentoo.org home to host these. This makes sure that the file won't be deleted from all its sources if the ebuild is removed (or more likely replaced) from tree. Ask the Emacs team how easy has been to recover gentoo-syntax files before. What is your feeling about projects that use tags in their source repositories and have a way to build the tarball directly from the repository? e.g. for openrc, if you have a clone of the repository you can do: git checkout [tag] make dist and you will have the same tarball that we released. What about things hosted on github? I am upstream for some code hosted there and they prefer that you do not upload source tarballs, but use tags in your repository which will automatically be propegated to your downloads page. Your input would be appreciated. William pgp7UOrfGy8ks.pgp Description: PGP signature
[gentoo-dev] rfc: libexec directory inconsistency
All, I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be $(get_libdir)/foo, which puts things in different directories depending on whether the system is multilib or not. I enquired from Robin why we do this, and I was told that libexec is supposed to contain things which are not abi specific, but we do not enforce that for /, even though we do for /usr. Is there a reason for this? If not, would it break things if we start using /libexec as well as /usr/libexec? William pgplQuaFBmT5i.pgp Description: PGP signature
[gentoo-dev] Re: Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
Theo Chatzimichos posted on Sat, 22 Jan 2011 14:32:34 +0200 as excerpted: - On one hand, I would like user repositories to have a separate namespace, so that other users realize a given repo is NOT from a developer. - On the other side, what do we do when a user with a repo becomes a developer (and when they retire?) Well, the distinction for unofficial/official overlays happen mostly in layman -L, I don't think users pay attention to our git repo list. Furthermore, I got at least three requests from developers to move their repo from user/ to dev/ (same problem when devs retired). This distinction doesn't make any sense. Agreed with the layman distinction being the practical one for those using it. However, for site browsers the distinction could still be useful, and I prefer it in the filesystem layout rather than as a label. Does the symlink concept work? If so, what about a generic people subtree, with dev and user either at the same level or inside people, along with the list. Then simply symlink the individual repos to either dev or user as appropriate (or only have the dev subcase/symlink, so people can choose either dev specifically, or all users including devs). Layman could use the generic people path regardless so the path never changes, and its user/dev description could be updated along with the symlinks. Meanwhile, site browsers could choose to browse the generic version or the user/dev specific listings, as they wished. Tho with layman being the interface most will see and use in general, labels in the browser interface would probably do. I just prefer the filesystem layout distinction, especially if it's as trivial as managing a few symlinks. -- 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
[gentoo-dev] Re: On hosting self-produced distfiles
Il giorno sab, 22/01/2011 alle 10.20 -0600, William Hubbs ha scritto: What is your feeling about projects that use tags in their source repositories and have a way to build the tarball directly from the repository? I have written that already: can you provide a SHA512 identity of the file? The same tarball is not really sufficient. In general, though, for Gentoo-produced distfiles the archive _will_ have to host the files, even if Git provides an easy way to deal with that. What about things hosted on github? I am upstream for some code hosted there and they prefer that you do not upload source tarballs, but use tags in your repository which will automatically be propegated to your downloads page. GitHub _used_ to be broken and provide non-stable downloads, but they have since fixed that and the download of a tag will always have the same SHA512 digest, so it's just fine. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On 01/22/11 13:32, Theo Chatzimichos wrote: Well, the distinction for unofficial/official overlays happen mostly in layman -L, I don't think users pay attention to our git repo list. Furthermore, I got at least three requests from developers to move their repo from user/ to dev/ (same problem when devs retired). This distinction doesn't make any sense. Three request over what time? Compared to a screen height of user repos created, maybe that's not much. Sebastian
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On 01/22/11 09:55, Robin H. Johnson wrote: - On one hand, I would like user repositories to have a separate namespace, so that other users realize a given repo is NOT from a developer. Seconding that. - On the other side, what do we do when a user with a repo becomes a developer (and when they retire?) To avoid a move, you'd have to give away distinction. To be able to do path-based distinction, you have to move on status updates. It seems that you cannot have both at the same time. Sebastian
[gentoo-dev] Lastrite: thunar-thumbnailers, mousepad, gion-icon-theme
# Samuli Suominen ssuomi...@gentoo.org (22 Jan 2011) # Replaced by xfce-extra/tumbler # Removal in 30 days xfce-extra/thunar-thumbnailers # Samuli Suominen ssuomi...@gentoo.org (22 Jan 2011) # Included in gnome-themes-extras package wrt bug 351020. # Removal in 30 days. x11-themes/gion-icon-theme # Samuli Suominen ssuomi...@gentoo.org (22 Jan 2011) # Printing is broken because of xfprint requirement. # Package is using deprecated libxfcegui4 instead of libxfce4ui. # No development in about year at upstream git. # # Use app-editors/leafpad instead. # # Masked for removal in 30 days. app-editors/mousepad
[gentoo-dev] Re: rfc: libexec directory inconsistency
Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto: Is there a reason for this? If not, would it break things if we start using /libexec as well as /usr/libexec? More or less and yes, it would create one more root directory that has no real usage to be there anyway... I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be $(get_libdir)/foo, which puts things in different directories depending on whether the system is multilib or not. Which is wrong, it should be /lib/foo instead, not $(get_libdir), to follow what udev and other software in Linux has been using for a very long time now. The one problem we have here is that for reason I don't know, no-multilib profiles started using lib64 exclusively instead of the (proper) lib exclusively... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Sat, Jan 22, 2011 at 03:02:59PM -0100, Jorge Manuel B. S. Vicetto wrote: Well, the distinction for unofficial/official overlays happen mostly in layman -L, I don't think users pay attention to our git repo list. Furthermore, I got at least three requests from developers to move their repo from user/ to dev/ (same problem when devs retired). This distinction doesn't make any sense. Instead of relying on the name space for such a distinction, I propose we use a label for that. Preferably we should have an automatic system to produce the label and have it present on any online repo browsers (gitweb?) and on project management apps (redmine?) so that users have no doubt when looking at projects.gentoo.org / overlays.gentoo.org about the type of a repo. The label to distinguish between developers and non-developers repos could take advantage of the ldap info. We could also use labels for the status of a project like we're already doing on layman. The existence of labels is completely irrelevant to the actual PATH to the repos, of which there can be only one, and changing it later is going to upset people. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] rfc: libexec directory inconsistency
On Sat, Jan 22, 2011 at 12:02 PM, William Hubbs wrote: I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be $(get_libdir)/foo, which puts things in different directories depending on whether the system is multilib or not. I enquired from Robin why we do this, and I was told that libexec is supposed to contain things which are not abi specific, but we do not enforce that for /, even though we do for /usr. Is there a reason for this? If not, would it break things if we start using /libexec as well as /usr/libexec? /libexec is also a horrible wart which we have avoided on purpose. *BSD systems might use it, but we dont in Linux. i dont think the multilib issue is terribly relevant unless the files in question are used externally. with dhcpcd and openerc, the files are only used internally, so keeping them in the native multilib dir isnt an issue. -mike
