[gentoo-dev] Re: Is /var/cache the right place for repositories?
> On Fri, 21 Dec 2012, Duncan wrote: >>> The FHS says: >>> >>>/var/cache is intended for cached data from applications. Such >>>data is locally generated as a result of time-consuming I/O or >>>calculation. The application must be able to regenerate or >>>restore the data. > I'd been wondering about the point others have made about "locally > generated", vs "Internet downloaded". > However, upon rereading the above FHS quote, it hit me -- "from > applications... locally generated... as a result of time-consuming > I/O" is actually pretty explicit. I believe the emphasis has been on > "locally generated", and the point that it explicitly includes "as a > result of time-consuming I/O" in the definition of "locally > generated" has been missed entirely. I know I missed it. But, if > internet downloads triggered by running a local app don't qualify as > "generated as a result of time-consuming I/O", what other I/O-basis > generated files DO qualify as cache? That seems to pretty explicitly > include Internet downloads in the definition, to me! While this might be true for distfiles, Portage doesn't use the local copy of the tree as a cache. A normal emerge command doesn't trigger a download of the tree. And if the tree was removed, emerge doesn't work. Ulrich
[gentoo-dev] Re: Wordiness
Matt Turner posted on Thu, 20 Dec 2012 22:29:09 -0800 as excerpted: > On Thu, Dec 20, 2012 at 10:09 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> >> > Do you realize that you just wrote a two-and-a-half page single-spaced > thousand-word email? Seriously, this is way too much. This mailing list > is way too much. 173 lines (of about 72 chars) according to my client (reporting the value given in the gmane overviews, I believe). 150+, including quoted material of perhaps 20-50 lines, aren't unusual here. 400+ are not unheard of. I was posting a bit of gentoo history behind a policy in question. History tends to /be/ a bit wordy at a reasonable level of detail, as necessary there to explain the reasoning[1] behind the policy being questioned. --- [1] Again, as I understand it, subject to correction by others there and closer to the process. No claims of infallibility here! -- 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: Is /var/cache the right place for repositories?
Alexandre Rostovtsev posted on Thu, 20 Dec 2012 13:10:38 -0500 as excerpted: > On Thu, 2012-12-20 at 18:27 +0100, Ulrich Mueller wrote: >> The FHS says: >> >>/var/cache is intended for cached data from applications. Such data >>is locally generated as a result of time-consuming I/O or >>calculation. The application must be able to regenerate or restore >>the data. >> >> Now I wonder: After removal of e.g. the Portage tree from a system, it >> is generally not possible to restore it. (It can be refetched, but not >> to its previous state.) >> >> Same is true for distfiles > But I think that the main portage and overlay checkouts are already > cache-like in the sense that any manual user changes are automatically > overwritten by "emerge --sync" / "layman -S", which the users are > supposed to run on a sufficiently regular basis. So /var/cache does seem > like a reasonable place for them. I'd been wondering about the point others have made about "locally generated", vs "Internet downloaded". However, upon rereading the above FHS quote, it hit me -- "from applications... locally generated... as a result of time-consuming I/O" is actually pretty explicit. I believe the emphasis has been on "locally generated", and the point that it explicitly includes "as a result of time-consuming I/O" in the definition of "locally generated" has been missed entirely. I know I missed it. But, if internet downloads triggered by running a local app don't qualify as "generated as a result of time-consuming I/O", what other I/O-basis generated files DO qualify as cache? That seems to pretty explicitly include Internet downloads in the definition, to me! -- 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] Wordiness
On Thu, Dec 20, 2012 at 10:09 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Do you realize that you just wrote a two-and-a-half page single-spaced thousand-word email? Seriously, this is way too much. This mailing list is way too much.
[gentoo-dev] Re: Time based retirements
Rich Freeman posted on Thu, 20 Dec 2012 22:33:55 -0500 as excerpted: > On Thu, Dec 20, 2012 at 10:21 PM, Doug Goldstein > wrote: >> I could MAYBE understand it if they're consuming some valuable resource >> that we need to free up by retiring them. But instead they get a >> nasty-gram about their impending retirement and decide if that's how >> they are to be treated that they can be retired. > > Could anybody post the text of one of these "nasty grams?" > > I can understand the sense in just checking in to make sure a developer > still is interested in Gentoo and wants to retain cvs access. However, > I think the bar for keeping access should be kept low - they shouldn't > be forced to go find some trivial change to make just to get their name > in the logs. > > Sure, sometimes real life gets busy, but if a dev still runs Gentoo and > has interest they're fairly likely to return when life settles down. Obviously I can't post the text of one of these "nasty grams", but I was around when the idea was first discussed and then implemented, by undertakers and infra, with the blessing of either council or whatever it was that came before (I was young in gentoo back then and didn't have a clear understanding of how it all worked, but when I started, drobbins was still around, but in the process of setting up the foundation and etc so he could leave gentoo in good shape when he did retire, and IIRC/ AFAIK, he had turned things over to some sort of interrim executive committee... and I don't recall whether the events here predated what we call council today, or not). You're essentially correct, Rich. IIRC (and all this based on my possibly inaccurate understanding), at least one of the initial triggers was infra's concern, I believe after some other distro had a headline breakin when an inactive dev had their system penetrated and their credentials stolen, that the at-the-time-something like 500+ devs on the rolls, with something under 300 having any CVS or list activity at all within the last six months or some such (so about half were even minimally "active", this was of course before overlays became in any way widespread or more than personal overlays, tho some devs did make theirs publicly available), wasn't healthy, and was taking too much risk, due to the number of still active but potentially abandoned credentials out there, possibly free for the taking, with the credentialed no longer active, so they'd not even notice the activity in their name, that they hadn't done! The other primary concern was QA related, all those effectively abandoned packages could now be put up for adoption by new maintainers or for maintainer-needed or treecleaning, as appropriate based on open bug count, etc. As it was originally setup, the idea was that anybody without an away file explaining the situation, that hadn't had sufficient activity (CVS or list, I believe two commits or posts was to be considered sufficiently active) for at least (I believe) 90 days, would get an inquiry note from undertakers. That level of the process was supposed to be mostly scripted, a script was to be run periodically that would check for away files, cvs commits, and list posts, and would generate a list of inactive devs and the notices automatically, altho I THINK actually SENDING the notices might have required undertaker action, in which case the human doing that was supposed to review them for sanity. The idea was *NOT* that it would be a "nastygram", simply a note of concern, asking what was going on and if the dev was still interested in gentoo, or if they wanted to retire. Again, the primary interest, as best I know, was security. All those potentially unsupervised access credentials laying around for the taking, should someone get access to the inactive dev's computers, etc. If they were still interested, at the first level (which was IIRC 90 days), all they had to do was reply, saying so. *ONLY*, and this was a point that everyone took pains to ensure was specifically made, if people didn't reply (or replied that they were no longer interested in gentoo), were they ultimately retired. ** It's also worth pointing out that a simple away file listing something reasonable (that wasn't itself expired by this much time, but that bit wasn't automated, the automated script simply checked for an away file, period) would immediately shut down the process. I believe there was a second level that actually triggered the beginning of the undertaker process, at the 180 day (probably plus 30 days to give a last chance for a reply, which would have made it 210 days total, but I'm not positive on that). By this point, the thinking went, a dev really SHOULD have had at LEAST the time to setup an away file, or simply reply with an explanation so they could be entered in an ignore list, if they weren't already active once again. But, the argument went, anybody that couldn't post AT LEAST
Re: [gentoo-dev] Time based retirements
On 12/20/12 7:21 PM, Doug Goldstein wrote: > I'm curious who had the brain dead idea to retire Gentoo developers > that are still interested in the distro, that maintain low activity > packages for herds that are stretched way too thin, and are still > contributing to the distro in many ways other than direct CVS commits > (e.g. overlays, user support, providing hardware to other devs, etc). Dough, thank you for rising the issue. I'm receiving the undertakers@ e-mail, so I have a pretty good view of what's happening. I have several suggestions how we can improve things: 1. 3 months is too short period anyway. 2. Think through what the goals are. We do not want to retire as many people as possible. We do not want to frustrate people who do contribute to Gentoo. We do not want to discourage people who consider becoming new developers. At least I don't. 3. I think what's important is to keep packages maintained. I consider maintainership to be a duty, not a privilege. If someone is listed in metadata.xml, but is not really maintaining the package, that creates a formal illusion that the package is maintained, and may prevent other people from stepping up and taking maintenance of that package. 4. I suggest that we focus on the above: keeping packages maintained. Taking packages out of hands of inactive/overworked maintainers is good. They can always become _more_ active, which is easier if they retain cvs access. If they make a single commit every 3-6 months, I'm fine with that as long as things are maintained properly. 5. Remember that cvs/bugzilla activity is not the only way of contributing. It's probably most tanglible and very needed, but let's not reduce real people and their real world situations, and their effort to contribute to just dates and numbers. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing
On Thu, Dec 20, 2012 at 11:08 PM, Greg KH wrote: > On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote: >> 1. Are you party to any *copyright assignment* (eg FSF copyright assignment)? > > You need to rephrase this to be (in order for it to make any sense): > Are you party to any *copyright assignment* that is not part of your > employment agreement? > > Otherwise, everyone in the US, and most other countries, would almost > always have to just say "yes" to this, as their employer owns the > copyright for their work no matter what it is done on (open source or > not.) Work done for hire is certainly owned by the employer, unless an agreement to the contrary is explicitly documented, but employment agreements that purport to assign copyright for works unrelated to employment to the employer are rare. Maybe they're not as rare in the software industry, but most people aren't employed in the software industry (even if most Gentoo developers might be - though perhaps not as a big a majority as you might expect). Certainly I haven't signed any kind of document that assigns ownership of works created on my own time to my employer, and the legality of any contract I did sign to that effect would be dubious. > > Remember, in the US, individuals who actually own the copyright on the > work they do is quite rare once they get out of college, and even then, > while in college, the school does have the right to assert copyright > ownership of the work, depending on what it was done on/for (who > provided the equipment, tasks, etc.) Ownership of "work" in the sense of something you're paid to do usually does tend to reside with whoever is paying you to do the work, unless you're a consultant of some kind or otherwise paid by the engagement (in which case it is usually spelled out). Ownership of stuff like the photos everybody will be taking next week with family rarely ends up belonging to an employer. Don't get me wrong, if somebody is being paid by the Linux Foundation to update packages in various distros I could certainly see how that could be considered a work for hire. However, such arrangements are rare even in the open source world. However, as you've pointed out those situations do exist and the contributions covered by them are often important. If we were to pursue assignment of some kind, then I'm thinking that a voluntary arrangement like the one used by KDE would make more sense. However, about the only thing that would really help with is keeping the copyright notice simple (if Gentoo owns 50+% of a file we could probably just put "Copyright 2012 Gentoo Foundation" on it, but don't quote me on that as I'd like to get some confirmation on that and find out what others are doing). It probably wouldn't be worth the trouble unless it could be semi-automated (Google collects CLA signatures electronically - and electronic signatures are a whole separate mess of law - the legal standards are pretty low but I really wonder how well they'd stand up if somebody wanted to repudiate one). Rich
Re: [gentoo-dev] Time based retirements
Peter Stuge wrote: > > I think the bar for keeping access should be kept low - they > > shouldn't be forced to go find some trivial change to make just > > to get their name in the logs. > > When I first started looking into becoming a Gentoo developer I got a > very strong and very clear impression that this would be absolutely > neccessary not to get kicked out again. I still find that really > unfriendly, just like all the other bad stuff about Gentoo. To be clear, by unfriendly I mean the things I subjectively consider make Gentoo less awesome *for me*. There aren't many of them but there are a few. I understand that they all have their reason for being there. I don't neccessarily agree with them, but that's not the point, just like it isn't the point that there is some stuff that I don't like. > Desinformation is IMO always worse than no information. This line is the point. //Peter
Re: [gentoo-dev] Time based retirements
Rich Freeman wrote: > I think the bar for keeping access should be kept low - they > shouldn't be forced to go find some trivial change to make just > to get their name in the logs. When I first started looking into becoming a Gentoo developer I got a very strong and very clear impression that this would be absolutely neccessary not to get kicked out again. I still find that really unfriendly, just like all the other bad stuff about Gentoo. I've since understood that the documentation I had read is simply incorrect, does not reflect reality, but it seemed quite authoritative when I read it. Desinformation is IMO always worse than no information. //Peter
Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing
On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote: > On Mon, Dec 17, 2012 at 01:16:25PM -0800, Greg KH wrote: > > On a personal note, if any copyright assignment was in place, I would > > never have been able to become a Gentoo developer, and if it were to be > > put into place, I do not think that I would be allowed to continue to be > > one. I'm sure lots of other current developers are in this same > > situation, so please keep that in mind when reviewing this process. > This is a question for gregkh primarily, but I would also like to extend > it to all other Gentoo developers. > > 1. Are you party to any *copyright assignment* (eg FSF copyright assignment)? You need to rephrase this to be (in order for it to make any sense): Are you party to any *copyright assignment* that is not part of your employment agreement? Otherwise, everyone in the US, and most other countries, would almost always have to just say "yes" to this, as their employer owns the copyright for their work no matter what it is done on (open source or not.) Remember, in the US, individuals who actually own the copyright on the work they do is quite rare once they get out of college, and even then, while in college, the school does have the right to assert copyright ownership of the work, depending on what it was done on/for (who provided the equipment, tasks, etc.) > 2. Are you party to any *contributor license agreements* (eg FLA, Google CLA, > ...)? [2] > 3. Are you party to any other *license assertions* (eg DCO)? [3] > 4. Are you party to or aware of any other copyright aggregation efforts? [4] Note also, anyone who works for any company, might not be allowed to answer some of these questions, and, might not want to (i.e. the employer is requiring the person to do the work on a specific project, despite the fact that the developer doesn't like the copyright assignment rules for it.) I think you want to rephrase this as asking what types of projects, from a copyright assignment basis, do people contribute to, on their own time. But even then, you will run into problems with corporate restrictions. Hm, this is a mess. What are you trying to find out here? What type of projects to people work on based on the copyright assignment rules? Or something else? thanks, greg k-h
Re: [gentoo-dev] Packages up for grabs
On 20 December 2012 16:52, Pacho Ramos wrote: > Due araujo no longer taking care of them: > dev-lang/pike I've got this one :)
Re: [gentoo-dev] Time based retirements
On Thu, Dec 20, 2012 at 7:21 PM, Doug Goldstein wrote: > I'm curious who had the brain dead idea to retire Gentoo developers > that are still interested in the distro, that maintain low activity > packages for herds that are stretched way too thin, and are still > contributing to the distro in many ways other than direct CVS commits > (e.g. overlays, user support, providing hardware to other devs, etc). > > I could MAYBE understand it if they're consuming some valuable > resource that we need to free up by retiring them. But instead they > get a nasty-gram about their impending retirement and decide if that's > how they are to be treated that they can be retired. When they finally > want to contribute again they have the lovely uphill of our dreadfully > painful recruitment process. > > I'm really just trying to understand the sense in this. > -- > Doug Goldstein > Probably best to give an example.
Re: [gentoo-dev] Time based retirements
On Thu, Dec 20, 2012 at 10:21 PM, Doug Goldstein wrote: > I could MAYBE understand it if they're consuming some valuable > resource that we need to free up by retiring them. But instead they > get a nasty-gram about their impending retirement and decide if that's > how they are to be treated that they can be retired. Could anybody post the text of one of these "nasty grams?" I can understand the sense in just checking in to make sure a developer still is interested in Gentoo and wants to retain cvs access. However, I think the bar for keeping access should be kept low - they shouldn't be forced to go find some trivial change to make just to get their name in the logs. Sure, sometimes real life gets busy, but if a dev still runs Gentoo and has interest they're fairly likely to return when life settles down. Quantity of contribution is not nearly as important as the contributions being net-positive. Rich
Re: [gentoo-dev] Time based retirements
Doug Goldstein wrote: > I'm really just trying to understand the sense in this. I guess that it's a bias. Everyone wants active developers. One way to achieve that is to retire anyone who isn't active. I would prefer another approach, but I also understand that Gentoo has had massive people issues in the past. //Peter
[gentoo-dev] Time based retirements
I'm curious who had the brain dead idea to retire Gentoo developers that are still interested in the distro, that maintain low activity packages for herds that are stretched way too thin, and are still contributing to the distro in many ways other than direct CVS commits (e.g. overlays, user support, providing hardware to other devs, etc). I could MAYBE understand it if they're consuming some valuable resource that we need to free up by retiring them. But instead they get a nasty-gram about their impending retirement and decide if that's how they are to be treated that they can be retired. When they finally want to contribute again they have the lovely uphill of our dreadfully painful recruitment process. I'm really just trying to understand the sense in this. -- Doug Goldstein
Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing
On Mon, Dec 17, 2012 at 01:16:25PM -0800, Greg KH wrote: > On a personal note, if any copyright assignment was in place, I would > never have been able to become a Gentoo developer, and if it were to be > put into place, I do not think that I would be allowed to continue to be > one. I'm sure lots of other current developers are in this same > situation, so please keep that in mind when reviewing this process. This is a question for gregkh primarily, but I would also like to extend it to all other Gentoo developers. 1. Are you party to any *copyright assignment* (eg FSF copyright assignment)? 2. Are you party to any *contributor license agreements* (eg FLA, Google CLA, ...)? [2] 3. Are you party to any other *license assertions* (eg DCO)? [3] 4. Are you party to or aware of any other copyright aggregation efforts? [4] [2] Contributor License Agreements: === Google CLA: http://code.google.com/legal/individual-cla-v1.0.html FSF Europe FLA: http://fsfe.org/activities/ftf/fla.en.html Oracle Contributor Agreement: http://www.oracle.com/technetwork/community/oca-486395.html The historical Sun Contributor Agreement and MySQL Community Contribution Agreement Many more here: http://en.wikipedia.org/wiki/Contributor_License_Agreement [3] License assertions: === http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches#l298 [4] Copyright aggregation: == Canonical's Project Harmony is the only aggregation effort I'm aware of. http://harmonyagreements.org/overview.html http://en.wikipedia.org/wiki/Project_Harmony_(FOSS_group) They provide an excellent guide to many of the nuances between copyright assignments and contributer agreements: http://harmonyagreements.org/guide.html -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
On 12/20/2012 03:00 PM, Ian Stakenvicius wrote: > > > sorry for the format, this was > Sent from my iPhone > > On 2012-12-20, at 4:51 PM, Ciaran McCreesh > wrote: > >> On Thu, 20 Dec 2012 15:09:45 -0500 >> Rich Freeman wrote: >>> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico >>> wrote: On 12/18/2012 11:58 PM, Duncan wrote: > I didn't know that. Last I knew, stable portage had special-case > acceptance of @system and @world to prepare the way, but I hadn't > seen that full /etc/portage/sets/* and /var/lib/portage/world_sets > support was stabilized. > > If indeed it is as you say, I've even more to rejoice about! =:^) Yeah, it's only been in stable for a few months now, so lots of people aren't aware of it yet. The current list available in portage-2.1.10.x, reported by emerge --list-sets is: preserved-rebuild >>> >>> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are >>> now stable, we should create a news item about this. >>> >>> Otherwise people will still be running revdep-rebuild a decade from >>> now, as this feature was never formally announced as far as I'm aware, >>> and all the mentions of it were ages ago and not available to stable >>> users at the time. >> >> We really shouldn't... EAPI 5 is the way to go, not preserve-libs. >> > > preserved-libs complements EAPI5, it should not disappear. Plus, if we are somehow able to do away with preserve-libs then we also need to ban preserve_old_lib from eutils.eclass, since it's the same thing only worse due to its lack of automatic garbage collection. -- Thanks, Zac
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
sorry for the format, this was Sent from my iPhone On 2012-12-20, at 4:51 PM, Ciaran McCreesh wrote: > On Thu, 20 Dec 2012 15:09:45 -0500 > Rich Freeman wrote: >> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico >> wrote: >>> On 12/18/2012 11:58 PM, Duncan wrote: I didn't know that. Last I knew, stable portage had special-case acceptance of @system and @world to prepare the way, but I hadn't seen that full /etc/portage/sets/* and /var/lib/portage/world_sets support was stabilized. If indeed it is as you say, I've even more to rejoice about! =:^) >>> >>> Yeah, it's only been in stable for a few months now, so lots of >>> people aren't aware of it yet. >>> >>> The current list available in portage-2.1.10.x, reported by emerge >>> --list-sets is: >>> >>> preserved-rebuild >> >> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are >> now stable, we should create a news item about this. >> >> Otherwise people will still be running revdep-rebuild a decade from >> now, as this feature was never formally announced as far as I'm aware, >> and all the mentions of it were ages ago and not available to stable >> users at the time. > > We really shouldn't... EAPI 5 is the way to go, not preserve-libs. > preserved-libs complements EAPI5, it should not disappear.
Re: [gentoo-dev] Keeping licenses around
> On Thu, 20 Dec 2012, Rich Freeman wrote:
>> If only a small subset of licenses require it, then maybe we should just
>> use dodoc on those licenses that require it. Saving all licenses could
>> be overkill.
> Seems like a reasonable compromise. I would think such licenses would
> be rare. I still think it is extralegal to try to require this, but
> some would rather not take risks and I can appreciate that...
The current solution is to install such licenses when USE="bindist"
is set. When installing from source, one can normally assume that
${PORTDIR}/licenses exists.
Ulrich
Re: [gentoo-dev] Is /var/cache the right place for repositories?
Ulrich Mueller schrieb: >> Now I wonder: After removal of e.g. the Portage tree from a system, >> it is generally not possible to restore it. (It can be refetched, >> but not to its previous state.) Is it required that the _exact_ _same_ _data_ will be regenerated? This is not the case with most users of /var/cache (like ccache for example). They only regenerate what is needed so the application continues to work properly. The ebuilds that are needed for portage functioning are saved to /var/db/pkg already. squid cache would be another example, or just about every other Linux distro's package manager. > What about /usr/portage/licenses, for example? Some of the licenses > are required to be present on the system if the corresponding software > is installed. So users cannot legally remove them. They are not required for functioning of the system, and a sync will restore them. > Should we really put them under /var/cache which suggests that > everything in there can be wiped? Yes. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
On Thu, 20 Dec 2012 15:09:45 -0500 Rich Freeman wrote: > On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico > wrote: > > On 12/18/2012 11:58 PM, Duncan wrote: > >> I didn't know that. Last I knew, stable portage had special-case > >> acceptance of @system and @world to prepare the way, but I hadn't > >> seen that full /etc/portage/sets/* and /var/lib/portage/world_sets > >> support was stabilized. > >> > >> If indeed it is as you say, I've even more to rejoice about! =:^) > > > > Yeah, it's only been in stable for a few months now, so lots of > > people aren't aware of it yet. > > > > The current list available in portage-2.1.10.x, reported by emerge > > --list-sets is: > > > > preserved-rebuild > > If @preserved-rebuild and the corresponding FEATURES=preserve-libs are > now stable, we should create a news item about this. > > Otherwise people will still be running revdep-rebuild a decade from > now, as this feature was never formally announced as far as I'm aware, > and all the mentions of it were ages ago and not available to stable > users at the time. We really shouldn't... EAPI 5 is the way to go, not preserve-libs. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Packages up for grabs
Due araujo no longer taking care of them: dev-lang/gnu-smalltalk dev-lang/gwydion-dylan-bin dev-lang/pike dev-lang/io signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, 20 Dec 2012 19:44:36 +0100
Ulrich Mueller wrote:
> > On Thu, 20 Dec 2012, Ciaran McCreesh wrote:
> >> We should go with a shorter (easier to remember, easier to type)
> >> path and move things at least one level up. Two would be even
> >> better.
>
> > You shouldn't ever be typing that path in...
>
> Ebuilds tell users to do so:
>
> pkg_nofetch() {
> einfo "Please download ${foo} and place it in ${DISTDIR}"
> }
>
I believe Unix has a facility for taking bits of text that are on the
screen and copying them without the need to type the whole thing in.
But in any case, DISTDIR shouldn't be under the repository dir at all.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] net-misc/sks up for grabs
After talking with Mike, sks is now up for grabs, feel free to take it Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Keeping licenses around
On Thu, Dec 20, 2012 at 3:46 PM, Zac Medico wrote: > > If only a small subset of licenses require it, then maybe we should just > use dodoc on those licenses that require it. Saving all licenses could > be overkill. Seems like a reasonable compromise. I would think such licenses would be rare. I still think it is extralegal to try to require this, but some would rather not take risks and I can appreciate that... Rich
Re: [gentoo-dev] Re: eudev project announcement
> We're drifting here, but the concept is that machine-local stuff like > configuration stays out of /usr, and generic distro stuff stays in > /usr. > > A webserver for site1 vs site2 would be identical in /usr, but > different elsewhere. That has always been the case. In fact people have tried to seperate /etc from / but it has proved too problematic. That's a different issue entirely. If the proposal was / (etc) /root /usr. I would be happy... if it worked. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
On 12/20/2012 12:35 PM, Pacho Ramos wrote: > El jue, 20-12-2012 a las 12:23 -0800, Zac Medico escribió: >> On 12/20/2012 12:09 PM, Rich Freeman wrote: >>> On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico wrote: On 12/18/2012 11:58 PM, Duncan wrote: > I didn't know that. Last I knew, stable portage had special-case > acceptance of @system and @world to prepare the way, but I hadn't seen > that full /etc/portage/sets/* and /var/lib/portage/world_sets support was > stabilized. > > If indeed it is as you say, I've even more to rejoice about! =:^) Yeah, it's only been in stable for a few months now, so lots of people aren't aware of it yet. The current list available in portage-2.1.10.x, reported by emerge --list-sets is: preserved-rebuild >>> >>> If @preserved-rebuild and the corresponding FEATURES=preserve-libs are >>> now stable, we should create a news item about this. >>> >>> Otherwise people will still be running revdep-rebuild a decade from >>> now, as this feature was never formally announced as far as I'm aware, >>> and all the mentions of it were ages ago and not available to stable >>> users at the time. >> >> It's not enabled by default yet though. In the following blog post I've >> mentioned that I would like to wait for EAPI 5 and automatic rebuilds >> (via sub-slots and slot-operators) to gain widespread adoption before >> preserve-libs is enabled by default: >> >> http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/ >> >> The reason that I want to wait is that EAPI 5 automatic rebuilds provide >> solutions for known problems with @preserved-rebuild. These problems >> include symbol collisions [1] and unnecessary rebuilding of packages >> that are eligible for removal by emerge --depclean [2]. >> >> [1] >> http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour >> [2] https://bugs.gentoo.org/show_bug.cgi?id=364425 > > Regarding symbol collisions, they would appear when people don't rebuild > packages after updating (and that would be solved with eapi5, no? But, > it's not exactly the same as is occurring currently if people forget to > run revdep-rebuild (or if it's partially run)? The problem with symbol collisions is only possible for people who have preserve-libs enabled. On the other hand, when preserve-libs is disabled, programs simply fail to run due to the libraries that they linked against having been unmerged when the library was updated. -- Thanks, Zac
Re: [gentoo-dev] Is /var/cache the right place for repositories?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/2012 01:14 PM, Ciaran McCreesh wrote: > On Thu, 20 Dec 2012 18:27:26 +0100 > Ulrich Mueller wrote: >> The FHS says: >> >>/var/cache is intended for cached data from applications. Such data >>is locally generated as a result of time-consuming I/O or >>calculation. The application must be able to regenerate or restore >>the data. >> >> Now I wonder: After removal of e.g. the Portage tree from a system, it >> is generally not possible to restore it. (It can be refetched, but not >> to its previous state.) >> >> Same is true for distfiles, at least to some degree. They may have >> vanished upstream or from mirrors. >> >> Maybe /var/lib would be a better choice? It would also take care of >> the issue with fetch-restricted files. > > The tree is a database. It belongs in /var/db/. > +1 and another +1 from my other personality, so +2 from us - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ03oTAAoJEKXdFCfdEflKKLYQAIJRRlt3xnh30rxbVi3T7Iuy tcx853ngIoyhc8fuhygDdsWPaIwa2WqOBuM6SuxiRlj3BDuL3sgSpMX3bWaL2ukK VXRJKZ2zVBOdc/KfbBvkWjN3P9nlOMMV8HGtGgwlniLF6BeeKlI2SqI8tWRX5bBN eUDbb1I0gSV1Tr1F3s9j5GSjd+kq17DloeXD4W0/uOEnN9Q+dvh8zMRA208ZY7qj B0f7TMgkh1ryy1OPSeXDlwgIjJbzgHWoDXN7RPiN/WF/E4msea/oq3tgz6TdTtdN sg+9VqqVXmJwHeMSpiQbR13JJ/I1pt+y9j8KgkUU5SGedyNYrzvaaSsy+ENdmVU2 JyEX5U+dFIgEo3uZX55fStGJyMWDoV5PmDkSUzDNyC2t1kgROYRh8JokGukqY3tL VKeFKwqysRmJfeLuFYbgsXezrQQrGD1PWsPt9yLoS5hFER89+A95d8f00tTv8mCe KAihOScCwtxl1PHfkOwB4BZJwdilwXBoKaAgT91Ul43GGabxYOMpCKfq2w9dzDT/ oMWPUrwIgJT/kdmBm2+TaLfwEfVHUCOhPaD5vqBeYJ2MJhZWr23VRlR5YUEf7E9W S+yBSiLkr2ZCVv3sZ80tRezN6FVZRKSJjIeZ11u7AWXN3hxtbvidJV+yL416/nJr 4rD8jfLJHHOvVaiX36JH =MnSP -END PGP SIGNATURE-
Re: [gentoo-dev] Keeping licenses around
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/2012 03:25 PM, Rich Freeman wrote: > On Thu, Dec 20, 2012 at 1:19 PM, Ian Stakenvicius wrote: >> On 20/12/12 01:12 PM, Ulrich Mueller wrote: >>> >>> What about /usr/portage/licenses, for example? Some of the >>> licenses are required to be present on the system if the >>> corresponding software is installed. So users cannot legally remove >>> them. > > Perhaps a better way to phrase that is that some of the licenses claim > that they are required to be present on the system if the > corresponding software is installed. > > Licenses can't make you do things - only laws can make you do things. > Licenses just give you the right to "break" a law. > > I think that this is legally very dubious. If people want to save > copies of license files they can of course do so, but I'm not sure it > is really worth a lot of effort to automate it. But, if somebody > wants to stick it in /var/db/pkg or whatever I guess it is just a few > thousand inodes... I'm pretty happy with only one copy of every license on my system... - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ03niAAoJEKXdFCfdEflKR3YP/30k+BOSTshaEmEJLgFhPxlI VcRpEXoRWr1UDDbTr8xNqYcPenPvslus5TpaBLMr4DQRYM2mKcMCcOSGGMr5kWzp wvEvfj+1EAUUu6xL2BgeMbLbRGyfBv+GwmPI1L+wvWgZhfo3tdGSimGZwGxA1mMI dx3Oi15d4TZsQGO4wvrgaCcbNaMDFEF6D65CewmJiPCmLljAZDMN3lxejr8bbGgp SjJOrlxAZckZnE6aXKtmZHeXu5YzjT2iVEat0ADjad0eR69/AaRfbLyd75Rp7rkL W7zKHnZv2d3P4UGi1vDM6EXPlJHil6F1ruUU6nvRHnyn89ndIF1xwIIKpuellWWD +11FXIJIWpF5+V2jWLPdZtxtp21Mr7Sphsr8s162ryHh7qWHzkCaaia8laX+EbwP k4IEfjP3wSWo71rKOxJsAMoJb3FPum4cM/GLh8eedIZMabODUL43B5uk4jkigZki /g1zwLCBXzbOjjGn1ngVCZKLWLKWh3qTo7VDBEa320L8UEKqxASehywd8TeUzWIb o7roPyau9LsHrHwuLi3stVsBsx8P+zN8s0+AFJSjKNbfWPY4+lcZjgFd8oceEAGk rWnBt2RJkjy6ODn1jVSAQpRrUqyiKonpk8FHDrk3g4e2NgZf4duIy2BOoLe5SiUi ao+vj/d1mfZVvhe8U/9F =Gc3+ -END PGP SIGNATURE-
Re: [gentoo-dev] Keeping licenses around
On 12/20/2012 10:19 AM, Ian Stakenvicius wrote: > On 20/12/12 01:12 PM, Ulrich Mueller wrote: > >> What about /usr/portage/licenses, for example? Some of the >> licenses are required to be present on the system if the >> corresponding software is installed. So users cannot legally remove >> them. > > > ... well, along those lines, the list of licenses are not pertinent > to the system unless the software that relates to them is installed; > maybe emerge should automatically during the merge phase ensure the > license files are copied to the main system in say /var/lib/licenses > or similar? If only a small subset of licenses require it, then maybe we should just use dodoc on those licenses that require it. Saving all licenses could be overkill. -- Thanks, Zac
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
El jue, 20-12-2012 a las 12:23 -0800, Zac Medico escribió: > On 12/20/2012 12:09 PM, Rich Freeman wrote: > > On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico wrote: > >> On 12/18/2012 11:58 PM, Duncan wrote: > >>> I didn't know that. Last I knew, stable portage had special-case > >>> acceptance of @system and @world to prepare the way, but I hadn't seen > >>> that full /etc/portage/sets/* and /var/lib/portage/world_sets support was > >>> stabilized. > >>> > >>> If indeed it is as you say, I've even more to rejoice about! =:^) > >> > >> Yeah, it's only been in stable for a few months now, so lots of people > >> aren't aware of it yet. > >> > >> The current list available in portage-2.1.10.x, reported by emerge > >> --list-sets is: > >> > >> preserved-rebuild > > > > If @preserved-rebuild and the corresponding FEATURES=preserve-libs are > > now stable, we should create a news item about this. > > > > Otherwise people will still be running revdep-rebuild a decade from > > now, as this feature was never formally announced as far as I'm aware, > > and all the mentions of it were ages ago and not available to stable > > users at the time. > > It's not enabled by default yet though. In the following blog post I've > mentioned that I would like to wait for EAPI 5 and automatic rebuilds > (via sub-slots and slot-operators) to gain widespread adoption before > preserve-libs is enabled by default: > > http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/ > > The reason that I want to wait is that EAPI 5 automatic rebuilds provide > solutions for known problems with @preserved-rebuild. These problems > include symbol collisions [1] and unnecessary rebuilding of packages > that are eligible for removal by emerge --depclean [2]. > > [1] > http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour > [2] https://bugs.gentoo.org/show_bug.cgi?id=364425 Regarding symbol collisions, they would appear when people don't rebuild packages after updating (and that would be solved with eapi5, no? But, it's not exactly the same as is occurring currently if people forget to run revdep-rebuild (or if it's partially run)? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, 20 Dec 2012 19:18:56 +0100 George Shapovalov wrote: > > It goes back a long time, and is basically a poor man's local > > overlay without having to use layman. As I understand it, portage > > will treat the directory like any other when looking for ebuilds > > and resolving deps, but exclude it from a sync. > Nope, he means /usr/portage/local, not /usr/local/portage. It is > rarely (if ever, nowadays) present, as I understand, but you can find > it mentioned in that config file. It may be just a legacy definition > by now, looking at how only layman was mentioned with relation to it > and even that one appears not to use it any more. I thought about this some more, and now realise I've been using essentially the same set of config files since about 2004. I've never lost them and always had a current copy so each time I build a new host I just copy, tweak CFLAGS, maybe MAKEOPTS, and let 'er rip. My "local" is probably years out of date. Serves me right for not reading 50 screens of man page with every new host :-) This sub-thread is probably just noise, sorry for that. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Keeping licenses around
On Thu, Dec 20, 2012 at 1:19 PM, Ian Stakenvicius wrote: > On 20/12/12 01:12 PM, Ulrich Mueller wrote: >> >> What about /usr/portage/licenses, for example? Some of the >> licenses are required to be present on the system if the >> corresponding software is installed. So users cannot legally remove >> them. Perhaps a better way to phrase that is that some of the licenses claim that they are required to be present on the system if the corresponding software is installed. Licenses can't make you do things - only laws can make you do things. Licenses just give you the right to "break" a law. I think that this is legally very dubious. If people want to save copies of license files they can of course do so, but I'm not sure it is really worth a lot of effort to automate it. But, if somebody wants to stick it in /var/db/pkg or whatever I guess it is just a few thousand inodes... Rich
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
On 12/20/2012 12:09 PM, Rich Freeman wrote: > On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico wrote: >> On 12/18/2012 11:58 PM, Duncan wrote: >>> I didn't know that. Last I knew, stable portage had special-case >>> acceptance of @system and @world to prepare the way, but I hadn't seen >>> that full /etc/portage/sets/* and /var/lib/portage/world_sets support was >>> stabilized. >>> >>> If indeed it is as you say, I've even more to rejoice about! =:^) >> >> Yeah, it's only been in stable for a few months now, so lots of people >> aren't aware of it yet. >> >> The current list available in portage-2.1.10.x, reported by emerge >> --list-sets is: >> >> preserved-rebuild > > If @preserved-rebuild and the corresponding FEATURES=preserve-libs are > now stable, we should create a news item about this. > > Otherwise people will still be running revdep-rebuild a decade from > now, as this feature was never formally announced as far as I'm aware, > and all the mentions of it were ages ago and not available to stable > users at the time. It's not enabled by default yet though. In the following blog post I've mentioned that I would like to wait for EAPI 5 and automatic rebuilds (via sub-slots and slot-operators) to gain widespread adoption before preserve-libs is enabled by default: http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/ The reason that I want to wait is that EAPI 5 automatic rebuilds provide solutions for known problems with @preserved-rebuild. These problems include symbol collisions [1] and unnecessary rebuilding of packages that are eligible for removal by emerge --depclean [2]. [1] http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour [2] https://bugs.gentoo.org/show_bug.cgi?id=364425 -- Thanks, Zac
Re: [gentoo-dev] Re: Portage sets support Was: Defaulting for debug information in profiles
On Wed, Dec 19, 2012 at 4:43 AM, Zac Medico wrote: > On 12/18/2012 11:58 PM, Duncan wrote: >> I didn't know that. Last I knew, stable portage had special-case >> acceptance of @system and @world to prepare the way, but I hadn't seen >> that full /etc/portage/sets/* and /var/lib/portage/world_sets support was >> stabilized. >> >> If indeed it is as you say, I've even more to rejoice about! =:^) > > Yeah, it's only been in stable for a few months now, so lots of people > aren't aware of it yet. > > The current list available in portage-2.1.10.x, reported by emerge > --list-sets is: > > preserved-rebuild If @preserved-rebuild and the corresponding FEATURES=preserve-libs are now stable, we should create a news item about this. Otherwise people will still be running revdep-rebuild a decade from now, as this feature was never formally announced as far as I'm aware, and all the mentions of it were ages ago and not available to stable users at the time. Rich
Re: [gentoo-dev] Moving our/portage stuff to var
On 12/20/2012 03:36 AM, Alan McKinnon wrote:
> On Wed, 19 Dec 2012 14:19:52 -0800
> Zac Medico wrote:
>
>> On 12/19/2012 02:01 PM, Alan McKinnon wrote:
>>> On Wed, 19 Dec 2012 14:56:44 +0100
>>> Diego Elio Pettenò wrote:
>>>
Just mv /usr/portage /var/portage ? FFS no. Among other things, as
many said before, we should really take distfiles out of the tree
itself, and packages the same. And I don't want /var/packages
or /var/distfiles at all.
>>>
>>> If we are going to move distfiles out of the tree into, what are the
>>> odds of getting /some/path/portage/local to move somewhere else too?
>>
>> What program uses this "local" directory? It's not used directly by
>> portage itself, though portage has an exclude for it in the default
>> PORTAGE_RSYNC_OPTS setting
>> (in /usr/share/portage/config/make.globals).
>
> It goes back a long time, and is basically a poor man's local overlay
> without having to use layman. As I understand it, portage will treat
> the directory like any other when looking for ebuilds and resolving
> deps, but exclude it from a sync.
Portage doesn't have any special handling for this directory, aside from
the exclude in the default PORTAGE_RSYNC_OPTS setting. I would not
encourage people to use this directory for anything, because it tends to
give people the impression that it's safe to store random things inside
$PORTDIR, while it's somewhat fragile given that it relies on special
rsync options. Occasionally, we get bug reports from people who have
lost files because of this sort of confusion:
https://bugs.gentoo.org/show_bug.cgi?id=131030
https://bugs.gentoo.org/show_bug.cgi?id=392565
>>
>>> That one has irked me for ages, its the one thing left on my systems
>>> that stops the local tree dir being an exact replica of the upstream
>>> master.
>>
>> For portage's defaults, I won't settle for anything less than having
>> them all refer to separate directories which are *not* nested within
>> one other. These are the current default settings which violate my
>> requirements:
>>
>> PORTDIR=/usr/portage
>> DISTDIR=${PORTDIR}/distfiles
>> PKGDIR=${PORTDIR}/packages
>> RPMDIR=${PORTDIR}/rpm
>
> /usr/portage/local has the taste feel and smell of a hacky workaround:
> shove a directory in the tree and exclude it from sync.
Right.
> I suspect the best solution all round is to move all support for local
> overlays into layman. I'd be happy with that. Probably make the portage
> code cleaner too.
As mentioned, portage doesn't have any special handling for this
directory (aside from the rsync exclude).
--
Thanks,
Zac
Re: [gentoo-dev] Moving our/portage stuff to var
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/12 01:55 PM, George Shapovalov wrote: > On Thursday 20 December 2012 13:21:11 Ian Stakenvicius wrote: >>> Nope, he means /usr/portage/local, not /usr/local/portage. >> >> Alan's description *was* for /usr/portage/local > Really? It matches /usr/local/portage pretty well. How did it come > around then? We had /usr/local/portage for ages for storing local > changes.. > /usr/local/portage has always been a convention or recommendation; it's not a directory that portage (package or tree) ever created, enforced, or did anything in particular to support. /usr/portage/local/ came around (i think -- i was around at this time but was not a dev and was not privy to decision making) so that locally modified ebuilds could be stored and distributed (ie via netmount or manual rsync) along with the rest of the portage tree without worries of the changes being wiped out on the next --sync. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDTZhEACgkQ2ugaI38ACPBEXwD+IuFOgsHcQDNaqUCUfSZW53ca 7gsST6Prls/7rPmpGqcBAKnnUIH48UPcDYrwexlNbmPzRN9CjYaeR36/2qo/hC47 =r5C9 -END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
Ian Stakenvicius wrote: "Such data is locally generated ... The application must be able to regenerate or restore the data." emerge --sync <-- regenerates/restores the portage tree Perhaps my English is too poor, but IMHO download != regenerate/restore. Indeed, the FHS also emphasizes only the *time* which it costs to regenerate the data in /var/cache and that it can be deleted without data loss (e.g. if your filesystem runs full). However, if you would do this e.g. on a laptop because you blindly trusted FHS you may have a lot of problems: Not only can it be quite expensive to "regenerate" the data (e.g. if you have to pay a lot for the bandwidth where you currently are), it might even be impossible if you have no internet connection at all or e.g. if you realize only after the deletion that you would have to (re)emerge some package to make the internet connection work (e.g. because you did not revdep-rebuild before). (And, yes, if you deal with distdir carefully, there are several occassions when you might want to (re)emerge a package even if you have no or only very limited internet connection; not only for revdep-rebuild but also e.g. if you need to change certain USE-Flags.) Of course, an experienced user knows and can care about this all, but an experienced user will choose the location anyway as he needs: We are speaking about the default which should mainly help also the less experienced user. download-restricted data whose sole location is in a cache dir is a decision made by the user. If you make /var/cache/... the default, this suggests the wrong decision to the user. At least, it should be documented then in a prominent place that the default path where the data is required is probably not the appropriate path to keep it (which IMHO is a bit strange). [...] PORTAGE_RO_DISTDIR [...] Maybe it would be pertinent to suggest and/or include a default path for this? This would be a good idea anyway, also because of theoretically possible name collisions in distdir. Martin
Re: [gentoo-dev] Moving our/portage stuff to var
On 12/20/2012 06:12 AM, Graham Murray wrote: > Zac Medico writes: > >> On 12/19/2012 02:01 PM, Alan McKinnon wrote: >>> If we are going to move distfiles out of the tree into, what are the >>> odds of getting /some/path/portage/local to move somewhere else too? >> >> What program uses this "local" directory? It's not used directly by >> portage itself, though portage has an exclude for it in the default >> PORTAGE_RSYNC_OPTS setting (in /usr/share/portage/config/make.globals). > > It is useful for 'site' local ebuilds. It allows a 'master' repository > to sync with the main Gentoo one without disturbing local changes but > allow other systems on-site to fetch the modified tree with a simple > 'emerge --sync'. This usage is slightly annoying, because it tends to give people the impression that it's safe to store random things inside $PORTDIR, while it's somewhat fragile given that it relies on special rsync options. Occasionally, we get bug reports from people who have lost files because of this sort of confusion: https://bugs.gentoo.org/show_bug.cgi?id=131030 https://bugs.gentoo.org/show_bug.cgi?id=392565 -- Thanks, Zac
Re: [gentoo-dev] Moving our/portage stuff to var
On Thursday 20 December 2012 13:21:11 Ian Stakenvicius wrote: > > Nope, he means /usr/portage/local, not /usr/local/portage. > > Alan's description *was* for /usr/portage/local Really? It matches /usr/local/portage pretty well. How did it come around then? We had /usr/local/portage for ages for storing local changes..
Re: [gentoo-dev] Moving our/portage stuff to var
> On Thu, 20 Dec 2012, Ciaran McCreesh wrote:
>> We should go with a shorter (easier to remember, easier to type) path
>> and move things at least one level up. Two would be even better.
> You shouldn't ever be typing that path in...
Ebuilds tell users to do so:
pkg_nofetch() {
einfo "Please download ${foo} and place it in ${DISTDIR}"
}
Re: [gentoo-dev] Moving our/portage stuff to var
Ciaran McCreesh wrote: > On Thu, 20 Dec 2012 18:44:06 +0100 > Ulrich Mueller wrote: >> There's no good reason for nesting it so deeply. As it is proposed >> above, /var/cache/portage would contain only two subdirectories, and >> /var/cache/portage/repositories only a single "gentoo" on a stable >> system. Also /var/cache itself isn't overpopulated; I count about ten >> entries on my systems. > You really think most people don't have to use overlays? > >> We should go with a shorter (easier to remember, easier to type) path >> and move things at least one level up. Two would be even better. > You shouldn't ever be typing that path in... > I was thinking tab completion myself. Just hit a couple letters and hit tab. That tab key types much faster and more accurately than I can. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, Dec 20, 2012 at 12:31 PM, William Hubbs wrote: > On Thu, Dec 20, 2012 at 06:58:11AM -0500, Rich Freeman wrote: >> On Thu, Dec 20, 2012 at 4:25 AM, George Shapovalov wrote: >> > On Thursday 20 December 2012 09:11:39 Ulrich Mueller wrote: >> >> > /var/cache/repositories/local<== the new location for a local >> >> > overlay >> >> >> >> Also I wonder if local overlays should be in /var/cache? It might not >> >> always be possible to restore them. >> > So, this is the present /usr/local/portage? What's wrong with it? >> > According to FHS, /usr/local/ is reserved for local admin meddling, which >> > fits >> > the bill rather nicely fo local overlay. This is the one location that was >> > actually making sense from the beginning. >> >> I actually like the /var/cache/repositories approach. You can always >> add a symlink to it if you want to for convenience (as I already do >> for /var/lib/portage/world). There is really nothing special about >> /usr/portage, other than it being the lowest-priority overlay. > > If we do this, I don't like the name repositories -- what kind of > repositories? should I put git repositories in there? I was pondering this, too. How about 'pms', for trees and overlays? -- :wq
Re: [gentoo-dev] Keeping licenses around
On 20/12/2012 19:19, Ian Stakenvicius wrote: > ... well, along those lines, the list of licenses are not pertinent > to the system unless the software that relates to them is installed; > maybe emerge should automatically during the merge phase ensure the > license files are copied to the main system in say /var/lib/licenses > or similar? Why not in their own /var/db/pkg then? And +1 on this, it's something I was wondering myself some time ago. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, 20 Dec 2012 18:44:06 +0100 Ulrich Mueller wrote: > There's no good reason for nesting it so deeply. As it is proposed > above, /var/cache/portage would contain only two subdirectories, and > /var/cache/portage/repositories only a single "gentoo" on a stable > system. Also /var/cache itself isn't overpopulated; I count about ten > entries on my systems. You really think most people don't have to use overlays? > We should go with a shorter (easier to remember, easier to type) path > and move things at least one level up. Two would be even better. You shouldn't ever be typing that path in... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Moving our/portage stuff to var
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/12 01:18 PM, George Shapovalov wrote: > On Thursday 20 December 2012 13:36:27 Alan McKinnon wrote: >>> What program uses this "local" directory? It's not used >>> directly by portage itself, though portage has an exclude for >>> it in the default PORTAGE_RSYNC_OPTS setting (in >>> /usr/share/portage/config/make.globals). >> >> It goes back a long time, and is basically a poor man's local >> overlay without having to use layman. As I understand it, portage >> will treat the directory like any other when looking for ebuilds >> and resolving deps, but exclude it from a sync. > Nope, he means /usr/portage/local, not /usr/local/portage. Alan's description *was* for /usr/portage/local -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDTVxYACgkQ2ugaI38ACPAEnQD/fo3/VbYD32yZMUuaEB0zZHES 71qGChzegSgxLqV01FoA/i583ha2AX+xLdw9/tyC7HUkzQ+9jXbqWKoT4Jay6bHc =dt7h -END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
On 20 December 2012 17:44, Ulrich Mueller wrote:
>> On Thu, 20 Dec 2012, Michael Mol wrote:
>
> /var/cache/portage/distfiles
> /var/cache/portage/repositories/gentoo
> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
> /var/db/portage/repositories/{non-cache,repo,names,go,here}
>
>>> -1
>>>
>>> The subdirs are too deeply nested. (Ebuilds would be at the eighth
>>> level then...)
>
>> Maybe I missed something...but what's wrong with that?
>
> There's no good reason for nesting it so deeply. As it is proposed
> above, /var/cache/portage would contain only two subdirectories, and
> /var/cache/portage/repositories only a single "gentoo" on a stable
> system. Also /var/cache itself isn't overpopulated; I count about ten
> entries on my systems.
>
> We should go with a shorter (easier to remember, easier to type) path
> and move things at least one level up. Two would be even better.
>
>>> Let's put the tree in /var/cache/portage please, and distfiles in
>>> /var/cache/distfiles. Layman overlays can stay where they are, or
>>> move to /var/cache/layman.
>
> Ulrich
>
Yeah +1 to that. Makes more sense to me
--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
[gentoo-dev] Keeping licenses around
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/12 01:12 PM, Ulrich Mueller wrote: > > What about /usr/portage/licenses, for example? Some of the > licenses are required to be present on the system if the > corresponding software is installed. So users cannot legally remove > them. > ... well, along those lines, the list of licenses are not pertinent to the system unless the software that relates to them is installed; maybe emerge should automatically during the merge phase ensure the license files are copied to the main system in say /var/lib/licenses or similar? The system can exist with /usr/portage not installed at any given time, now (I have systems that NFS-mount it, but I only bother to do so when i'm going to emerge something). If licenses not existing is going to be a problem then we should resolve this no matter what. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDTVrYACgkQ2ugaI38ACPAHbwEAhXRKaWP4zFH6fRmWMcXJjUJk diGd9Dmwqe7EeRnSNZ0A/1En77FU6mI11FpVQZ5IMp16uSBPSbPoIePjbbz2PI0E =R/VK -END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
On Thursday 20 December 2012 13:36:27 Alan McKinnon wrote: > > What program uses this "local" directory? It's not used directly by > > portage itself, though portage has an exclude for it in the default > > PORTAGE_RSYNC_OPTS setting > > (in /usr/share/portage/config/make.globals). > > It goes back a long time, and is basically a poor man's local overlay > without having to use layman. As I understand it, portage will treat > the directory like any other when looking for ebuilds and resolving > deps, but exclude it from a sync. Nope, he means /usr/portage/local, not /usr/local/portage. It is rarely (if ever, nowadays) present, as I understand, but you can find it mentioned in that config file. It may be just a legacy definition by now, looking at how only layman was mentioned with relation to it and even that one appears not to use it any more. BTW, /usr/local/portage is hardly ""poor man's". Where are you going to store your local changes that are of interest only to you and not present in any other overlays? (like, you want to keep some old version of some package after it has been cleaned, or your personal mods). The location even accords to FHS, which is, apparently, a rarity :). George
Re: [gentoo-dev] Is /var/cache the right place for repositories?
On Thu, 20 Dec 2012 18:27:26 +0100 Ulrich Mueller wrote: > The FHS says: > >/var/cache is intended for cached data from applications. Such data >is locally generated as a result of time-consuming I/O or >calculation. The application must be able to regenerate or restore >the data. > > Now I wonder: After removal of e.g. the Portage tree from a system, it > is generally not possible to restore it. (It can be refetched, but not > to its previous state.) > > Same is true for distfiles, at least to some degree. They may have > vanished upstream or from mirrors. > > Maybe /var/lib would be a better choice? It would also take care of > the issue with fetch-restricted files. The tree is a database. It belongs in /var/db/. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Is /var/cache the right place for repositories?
> On Thu, 20 Dec 2012, Ian Stakenvicius wrote: > On 20/12/12 12:27 PM, Ulrich Mueller wrote: >> The FHS says: >> >> /var/cache is intended for cached data from applications. Such >> data is locally generated as a result of time-consuming I/O or >> calculation. The application must be able to regenerate or restore >> the data. >> >> Now I wonder: After removal of e.g. the Portage tree from a system, >> it is generally not possible to restore it. (It can be refetched, >> but not to its previous state.) >> >> Same is true for distfiles, at least to some degree. They may have >> vanished upstream or from mirrors. >> >> Maybe /var/lib would be a better choice? It would also take care >> of the issue with fetch-restricted files. > I had asked more or less the same thing a few days ago. The cases > where this would matter are few, however, and those users that need > the state preserved could ensure it by including these specific paths > in their backups and/or ensuring any cache-cleaner scripts (and AFAIK > there aren't any that wouldn't be custom-installed) do not remove them. What about /usr/portage/licenses, for example? Some of the licenses are required to be present on the system if the corresponding software is installed. So users cannot legally remove them. Should we really put them under /var/cache which suggests that everything in there can be wiped? Ulrich
Re: [gentoo-dev] Is /var/cache the right place for repositories?
On Thu, 2012-12-20 at 18:27 +0100, Ulrich Mueller wrote: > The FHS says: > >/var/cache is intended for cached data from applications. Such data >is locally generated as a result of time-consuming I/O or >calculation. The application must be able to regenerate or restore >the data. > > Now I wonder: After removal of e.g. the Portage tree from a system, it > is generally not possible to restore it. (It can be refetched, but not > to its previous state.) > > Same is true for distfiles, at least to some degree. They may have > vanished upstream or from mirrors. > > Maybe /var/lib would be a better choice? It would also take care of > the issue with fetch-restricted files. Due to fetch-restricted files, /var/lib does make sense for distfiles. And of course /var/lib should be used for the default personal overlay (currently in /usr/local/portage). But I think that the main portage and overlay checkouts are already cache-like in the sense that any manual user changes are automatically overwritten by "emerge --sync" / "layman -S", which the users are supposed to run on a sufficiently regular basis. So /var/cache does seem like a reasonable place for them.
Re: [gentoo-dev] Moving our/portage stuff to var
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/12 12:52 PM, Vaeth wrote: > > However, I have strong objections against using /var/cache at all: > FHS explicitly states: > > "Such data is locally generated ... The application must be able > to regenerate or restore the data." > emerge --sync <-- regenerates/restores the portage tree layman -s <-- regenerates/restores overlays emerge -f @world <-- regenerates/restores any distfiles of consequence download-restricted data whose sole location is in a cache dir is a decision made by the user. Note that current portage has a PORTAGE_RO_DISTDIR var which could be used to specify the path to these fetch-restricted downloads rather than the user putting them directly into /var/cache/distfiles/. Maybe it would be pertinent to suggest and/or include a default path for this? > What is really so bad about the current location under /usr as > default? There were some suggestions about this in the initial thread posts. But /usr/portage is certainly OK to remain as-is, we do not *need* to make any changes. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDTU/AACgkQ2ugaI38ACPDmmwD/XIrHlMiDBU7WPUjp9DILJwuq fM/y5zUVZcoD2W7kcuEA/jPV9l1BH8qsw3UQxJKi6zbjBweD0uJU28jxiX2ybdjo =lBlR -END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, 20 Dec 2012 07:37:52 -0800 Brian Dolbec wrote: > My idea for having all repos under one directory is to make it easier > for a pkg manager to simply scan the directory to know all installed > overlays. That's going to cause trouble, unless we start forcing overlays to contain enough information for a PM to configure them properly... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Is /var/cache the right place for repositories?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/12 12:27 PM, Ulrich Mueller wrote: > The FHS says: > > /var/cache is intended for cached data from applications. Such > data is locally generated as a result of time-consuming I/O or > calculation. The application must be able to regenerate or restore > the data. > > Now I wonder: After removal of e.g. the Portage tree from a system, > it is generally not possible to restore it. (It can be refetched, > but not to its previous state.) > > Same is true for distfiles, at least to some degree. They may have > vanished upstream or from mirrors. > > Maybe /var/lib would be a better choice? It would also take care > of the issue with fetch-restricted files. > I had asked more or less the same thing a few days ago. The cases where this would matter are few, however, and those users that need the state preserved could ensure it by including these specific paths in their backups and/or ensuring any cache-cleaner scripts (and AFAIK there aren't any that wouldn't be custom-installed) do not remove them. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDTUkgACgkQ2ugaI38ACPDgAwEAhFH3Jc8E56WfePr3W1396+Jk 65q7X8eEwNAYr8eJLwQA/1Xi7E42004M3frMDCDDBVZeD1EYmKkvXA8POhQUZc36 =JMod -END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
/var/cache/portage/distfiles
/var/cache/portage/repositories/gentoo
/var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
/var/db/portage/repositories/{non-cache,repo,names,go,here}
+1
-1
The subdirs are too deeply nested.
There is a practical advantage of having the main gentoo tree
and all overlays in the same directories which was not mentioned yet:
In this way it is easy to put them in a common filesystem appropriate
for this type of data (e.g. squashfs+aufs or whatever).
The same argument holds if you want to export the tree to several
systems: Probably all overlays should then be exported as well.
However, I have strong objections against using /var/cache at all:
FHS explicitly states:
"Such data is locally generated ... The application must be able to
regenerate or restore the data."
In my opinion it is rather clear that "regenerate" does not mean
"download". Not to speak about download-restricted data which
"the application" is certainly not able to regenerate.
(That locally maintained overlays do not fall into this category
is clear anyway; but again, it would be nice to have these possibly
on the same filesystem as all other ebuilds: Especially compressing
or other deduplicating filesystem would treat this better).
Therefore I would prefer another location.
Of course, on many systems, something under /srv might be the appropriate
place (especially if the tree should be exported); this should perhaps be
suggested to the user, although it is probably not a good idea to make
this the default, because any default can just be plain wrong for the
user's system.
What is really so bad about the current location under /usr as default?
Or maybe only split somewhat differently than currently like e.g.
/usr/portage/{gentoo,sunrise,...,local}
/usr/distiles
This would avoid the deep nesting, although it would allow a
common filesystem for the data of the same type.
As far as I can see, the argument against /usr/... is only that the
data is not "constant". But actually, it is as constant as all
other data in /usr: Usually emerge --sync is only called to do
an emerge afterwards which means that the data only needs to be
modified if you intend to modify /usr anyway...
Martin
Re: [gentoo-dev] Moving our/portage stuff to var
> On Thu, 20 Dec 2012, Michael Mol wrote:
/var/cache/portage/distfiles
/var/cache/portage/repositories/gentoo
/var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
/var/db/portage/repositories/{non-cache,repo,names,go,here}
>> -1
>>
>> The subdirs are too deeply nested. (Ebuilds would be at the eighth
>> level then...)
> Maybe I missed something...but what's wrong with that?
There's no good reason for nesting it so deeply. As it is proposed
above, /var/cache/portage would contain only two subdirectories, and
/var/cache/portage/repositories only a single "gentoo" on a stable
system. Also /var/cache itself isn't overpopulated; I count about ten
entries on my systems.
We should go with a shorter (easier to remember, easier to type) path
and move things at least one level up. Two would be even better.
>> Let's put the tree in /var/cache/portage please, and distfiles in
>> /var/cache/distfiles. Layman overlays can stay where they are, or
>> move to /var/cache/layman.
Ulrich
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, Dec 20, 2012 at 06:58:11AM -0500, Rich Freeman wrote: > On Thu, Dec 20, 2012 at 4:25 AM, George Shapovalov wrote: > > On Thursday 20 December 2012 09:11:39 Ulrich Mueller wrote: > >> > /var/cache/repositories/local<== the new location for a local overlay > >> > >> Also I wonder if local overlays should be in /var/cache? It might not > >> always be possible to restore them. > > So, this is the present /usr/local/portage? What's wrong with it? > > According to FHS, /usr/local/ is reserved for local admin meddling, which > > fits > > the bill rather nicely fo local overlay. This is the one location that was > > actually making sense from the beginning. > > I actually like the /var/cache/repositories approach. You can always > add a symlink to it if you want to for convenience (as I already do > for /var/lib/portage/world). There is really nothing special about > /usr/portage, other than it being the lowest-priority overlay. If we do this, I don't like the name repositories -- what kind of repositories? should I put git repositories in there? > As far as the local one goes - again this is configurable in > /etc/make.conf, and we don't really need to pre-create that directory > either. Right, there is nothing to pre-create for this; it should be left to the user. William pgpo5ORcGch97.pgp Description: PGP signature
[gentoo-dev] Is /var/cache the right place for repositories?
The FHS says: /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Now I wonder: After removal of e.g. the Portage tree from a system, it is generally not possible to restore it. (It can be refetched, but not to its previous state.) Same is true for distfiles, at least to some degree. They may have vanished upstream or from mirrors. Maybe /var/lib would be a better choice? It would also take care of the issue with fetch-restricted files. Ulrich
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, Dec 20, 2012 at 12:05 PM, Ulrich Mueller wrote:
>> On Thu, 20 Dec 2012, Diego Elio Pettenň wrote:
>
>>> /var/cache/portage/distfiles
>>> /var/cache/portage/repositories/gentoo
>>> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
>>> /var/db/portage/repositories/{non-cache,repo,names,go,here}
>
>> +1
>
> -1
>
> The subdirs are too deeply nested. (Ebuilds would be at the eighth
> level then...)
Maybe I missed something...but what's wrong with that?
>
> Let's put the tree in /var/cache/portage please, and distfiles in
> /var/cache/distfiles. Layman overlays can stay where they are, or move
> to /var/cache/layman.
--
:wq
Re: [gentoo-dev] Moving our/portage stuff to var
> On Thu, 20 Dec 2012, Diego Elio Pettenò wrote:
>> /var/cache/portage/distfiles
>> /var/cache/portage/repositories/gentoo
>> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
>> /var/db/portage/repositories/{non-cache,repo,names,go,here}
> +1
-1
The subdirs are too deeply nested. (Ebuilds would be at the eighth
level then...)
Let's put the tree in /var/cache/portage please, and distfiles in
/var/cache/distfiles. Layman overlays can stay where they are, or move
to /var/cache/layman.
Ulrich
Re: [gentoo-dev] Moving our/portage stuff to var
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/12/12 11:25 AM, Rick "Zero_Chaos" Farina wrote:
> On 12/20/2012 11:16 AM, Michael Mol wrote:
>> On Thu, Dec 20, 2012 at 11:01 AM, Ian Stakenvicius
>> wrote: On 20/12/12 10:37 AM, Brian Dolbec
>> wrote:
>>
>>> /var/cache/repositories/ /var/cache/repositories/gentoo
>>> <== the main portage tree /var/cache/repositories/local
>>> <== the new location for a local overlay
>>> /var/cache/repositories/some-overlay <== layman
>>> installed overlay
>
> My idea for having all repos under one directory is to make
> it easier for a pkg manager to simply scan the directory to
> know all installed overlays. Currently each one has to be
> listed in a configured variable in make.conf. So if you
> wanted your local overlay somewhere else, then a symlink
> would work (provided the PM can/will autoscan repos), or
> add it to the PORTDIR_OVERLAY variable (current behavior).
> I don't otherwise have a strong desire for it to be there.
>
> If and only if the tree and all overlays (not other
> directories) are not under one directory, then an autoscan
> cannot easily happen.
>
>
>
>> You could do this while not having the portage tree be in that
>> directory. IE, portage goes in /var/cache/portage , and all the
>> overlays go into /var/cache/repositories.
>
>> The tree is separate enough IMO that autoscan can still happen
>> easily, and also I believe that it can be assumed that the tree
>> is in place. For instance, if the tree's location is defined to
>> be elsewhere, it isn't done so via PORTDIR_OVERLAYS but rather
>> PORTDIR.
>
>
>> On an unrelated note, I would never treat my "local" overlays as
>> cache. Ebuilds that (as a user) I wrote and installed by hand
>> are not likely to be kept in a repository someplace, but rather
>> the overlay dir would most likely be it's only location. IIRC
>> the reason for /usr/portage/local/ was to have a path within the
>> portage tree that rsync wouldn't kill; given that what you're
>> suggesting is already not under the proposed portage tree
>> location, emerge --sync couldn't touch it, and so I don't see a
>> need at all to provide a 'local' repository destination by
>> default.
>
>>>
>
>> It's sounding like the nearly the optimal solution would be:
>
>> /var/cache/portage/distfiles
>> /var/cache/portage/repositories/gentoo
>> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
>>
>>
/var/db/portage/repositories/{non-cache,repo,names,go,here}
>
> Not to oversimplify but why exactly can't we leave
> /usr/local/portage where it is? I'm not going to want to cd
> /var/db/portage/repositories/local every time I want to edit a
> local ebuild...
>
> -ZC
>
IMO local user overlays would always end up being defined and placed
wherever the user decides them to be -- ie, /usr/local/portage as Rick
so nicely pointed out.
It may be a nice idea to try and enforce a structure to it/them, but
since PORTDIR_OVERLAY can be defined to include any path at all I
don't really see a point to it.
..I'm still with ulm about the tree not being in the repositories
subdir though. If I wanted to nuke all the overlays installed, "rm
- -Rf /var/cache/portage/repos/*" is very easy. If the tree is also in
that dir then it becomes less easy: "find /var/cache/portage/repos
- -maxdepth 1 -mindepth 1 -not -name gentoo -exec rm -Rf {} \+"
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlDTPlUACgkQ2ugaI38ACPBtPAD8DJ6BPjL6xY8alB5pbo7vQ5kb
dzRO9Z32F3r84RyVccABAIEu+k+ztw0ipoCwhmLlBHyiU6aEOsExixNvnMMLLu9X
=2gWT
-END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/20/2012 11:16 AM, Michael Mol wrote:
> On Thu, Dec 20, 2012 at 11:01 AM, Ian Stakenvicius wrote:
> On 20/12/12 10:37 AM, Brian Dolbec wrote:
>
>> /var/cache/repositories/ /var/cache/repositories/gentoo <==
>> the main portage tree /var/cache/repositories/local<== the
>> new location for a local overlay
>> /var/cache/repositories/some-overlay <== layman installed
>> overlay
My idea for having all repos under one directory is to make it
easier for a pkg manager to simply scan the directory to know all
installed overlays. Currently each one has to be listed in a
configured variable in make.conf. So if you wanted your local
overlay somewhere else, then a symlink would work (provided the PM
can/will autoscan repos), or add it to the PORTDIR_OVERLAY variable
(current behavior). I don't otherwise have a strong desire for it
to be there.
If and only if the tree and all overlays (not other directories)
are not under one directory, then an autoscan cannot easily
happen.
>
>
> You could do this while not having the portage tree be in that
> directory. IE, portage goes in /var/cache/portage , and all the
> overlays go into /var/cache/repositories.
>
> The tree is separate enough IMO that autoscan can still happen easily,
> and also I believe that it can be assumed that the tree is in place.
> For instance, if the tree's location is defined to be elsewhere, it
> isn't done so via PORTDIR_OVERLAYS but rather PORTDIR.
>
>
> On an unrelated note, I would never treat my "local" overlays as
> cache. Ebuilds that (as a user) I wrote and installed by hand are not
> likely to be kept in a repository someplace, but rather the overlay
> dir would most likely be it's only location. IIRC the reason for
> /usr/portage/local/ was to have a path within the portage tree that
> rsync wouldn't kill; given that what you're suggesting is already not
> under the proposed portage tree location, emerge --sync couldn't touch
> it, and so I don't see a need at all to provide a 'local' repository
> destination by default.
>
>>
>
> It's sounding like the nearly the optimal solution would be:
>
> /var/cache/portage/distfiles
> /var/cache/portage/repositories/gentoo
> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
> /var/db/portage/repositories/{non-cache,repo,names,go,here}
Not to oversimplify but why exactly can't we leave /usr/local/portage
where it is? I'm not going to want to cd
/var/db/portage/repositories/local every time I want to edit a local
ebuild...
- -ZC
>
> Clearly, some data in question needs to be treated as persistent, and
> others can be treated as cache. So it should probably be divided up
> that way. The placement of tree and overlays as subfolders of the same
> folder strikes me as appropriate, too.
>
> The only thing I can't see an elegant workaround for are how to avoid
> or handle repo name collisions between
> /var/cache/portage/repositories/* and /var/db/portage/repositories/*
>
> --
> :wq
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQIcBAEBAgAGBQJQ0zvlAAoJEKXdFCfdEflKfiEP/0uLujqLlv1DVydqj3xXZUVq
t/c5mDsg3iJgt5T7Hm+ER949r2GUqju4veed4JQWFlVSaOoLEViL1Me/jPco5fC8
v064ktt2hOLPb+tR2IWaK3tR8i+LhcFEcIyANhl62ENPWgvOAR6V0KNFuudQLicS
QUFaJYKZkkYuPSTTqPld3QXzFwH1X6RCQaOtjCOqZKAZr9iW8HRNTTLpoa4bSMgr
VBswHyH+q0C9TzIVv5u8G8s8cYNdqHf1wrSTeMjq961tVzF3Tno5s1zk1MOyQ7cQ
MkQCxiMAum0d9PX87UkPuvHKgLdZ7e+tW26B9bS3M9yGu66lsHB7+sOTxFAJ9kqp
YKLuO2XPmpIMyDNc/5rQtTl5ygA9CmqSpUZEjMgwvCmemOHO3CsPXXQxfq6Ze7kK
/aNfCHJVEP/x8bY7PdWoexaScW/Qnqrqm6R+GCd6B3LGmTinGaDWYzJj+pAkpGUn
OAHcxATC9gX3AZr9atTFHRaPkD3L3FdYothVDZq5DDkW2qAmuhbqaEhzytDI3GLl
R+MEWYcMqvNLV5eYlNPe4OOaYfFTr/1mP0k/3ixjxJFwMDXxmIaJGTKoMOyoPu3O
diZlo0m2EPCH7Ggl9Fh0xf4P/wDSQB0AkfyldQhnVNbR5DRcTrkU6IfJBVLdcJ40
XljVqWuG27XmMXwjLGgV
=NLJg
-END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, Dec 20, 2012 at 11:19 AM, Diego Elio Pettenò
wrote:
> On 20/12/2012 17:16, Michael Mol wrote:
>>
>> /var/cache/portage/distfiles
>> /var/cache/portage/repositories/gentoo
>> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
>> /var/db/portage/repositories/{non-cache,repo,names,go,here}
>
> +1
Agreed.
Look, we're not going to find any place that makes everybody happy.
This one seems to be logical from a design standpoint. As long as we
make sure that everything is set in configuration then individuals can
move it wherever they want to. Symlinks also work.
Rich
Re: [gentoo-dev] Moving our/portage stuff to var
On 20/12/2012 17:16, Michael Mol wrote:
>
> /var/cache/portage/distfiles
> /var/cache/portage/repositories/gentoo
> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
> /var/db/portage/repositories/{non-cache,repo,names,go,here}
+1
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, Dec 20, 2012 at 11:01 AM, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 20/12/12 10:37 AM, Brian Dolbec wrote:
>>>
/var/cache/repositories/ /var/cache/repositories/gentoo <==
the main portage tree /var/cache/repositories/local<== the
new location for a local overlay
/var/cache/repositories/some-overlay <== layman installed
overlay
>>
>> My idea for having all repos under one directory is to make it
>> easier for a pkg manager to simply scan the directory to know all
>> installed overlays. Currently each one has to be listed in a
>> configured variable in make.conf. So if you wanted your local
>> overlay somewhere else, then a symlink would work (provided the PM
>> can/will autoscan repos), or add it to the PORTDIR_OVERLAY variable
>> (current behavior). I don't otherwise have a strong desire for it
>> to be there.
>>
>> If and only if the tree and all overlays (not other directories)
>> are not under one directory, then an autoscan cannot easily
>> happen.
>>
>
>
> You could do this while not having the portage tree be in that
> directory. IE, portage goes in /var/cache/portage , and all the
> overlays go into /var/cache/repositories.
>
> The tree is separate enough IMO that autoscan can still happen easily,
> and also I believe that it can be assumed that the tree is in place.
> For instance, if the tree's location is defined to be elsewhere, it
> isn't done so via PORTDIR_OVERLAYS but rather PORTDIR.
>
>
> On an unrelated note, I would never treat my "local" overlays as
> cache. Ebuilds that (as a user) I wrote and installed by hand are not
> likely to be kept in a repository someplace, but rather the overlay
> dir would most likely be it's only location. IIRC the reason for
> /usr/portage/local/ was to have a path within the portage tree that
> rsync wouldn't kill; given that what you're suggesting is already not
> under the proposed portage tree location, emerge --sync couldn't touch
> it, and so I don't see a need at all to provide a 'local' repository
> destination by default.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iF4EAREIAAYFAlDTNlQACgkQ2ugaI38ACPCxQAEApT/7CaIbuVTwnDQk93hhDjGu
> mXKPdCJg4h1iMECtdoABAJj2601LuRPUKFJ+BJa/FqrdRTsjSpBRiEd8pvO2042P
> =W3T9
> -END PGP SIGNATURE-
>
It's sounding like the nearly the optimal solution would be:
/var/cache/portage/distfiles
/var/cache/portage/repositories/gentoo
/var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
/var/db/portage/repositories/{non-cache,repo,names,go,here}
Clearly, some data in question needs to be treated as persistent, and
others can be treated as cache. So it should probably be divided up
that way. The placement of tree and overlays as subfolders of the same
folder strikes me as appropriate, too.
The only thing I can't see an elegant workaround for are how to avoid
or handle repo name collisions between
/var/cache/portage/repositories/* and /var/db/portage/repositories/*
--
:wq
Re: [gentoo-dev] Moving our/portage stuff to var
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/12/12 10:37 AM, Brian Dolbec wrote: >> >>> /var/cache/repositories/ /var/cache/repositories/gentoo <== >>> the main portage tree /var/cache/repositories/local<== the >>> new location for a local overlay >>> /var/cache/repositories/some-overlay <== layman installed >>> overlay > > My idea for having all repos under one directory is to make it > easier for a pkg manager to simply scan the directory to know all > installed overlays. Currently each one has to be listed in a > configured variable in make.conf. So if you wanted your local > overlay somewhere else, then a symlink would work (provided the PM > can/will autoscan repos), or add it to the PORTDIR_OVERLAY variable > (current behavior). I don't otherwise have a strong desire for it > to be there. > > If and only if the tree and all overlays (not other directories) > are not under one directory, then an autoscan cannot easily > happen. > You could do this while not having the portage tree be in that directory. IE, portage goes in /var/cache/portage , and all the overlays go into /var/cache/repositories. The tree is separate enough IMO that autoscan can still happen easily, and also I believe that it can be assumed that the tree is in place. For instance, if the tree's location is defined to be elsewhere, it isn't done so via PORTDIR_OVERLAYS but rather PORTDIR. On an unrelated note, I would never treat my "local" overlays as cache. Ebuilds that (as a user) I wrote and installed by hand are not likely to be kept in a repository someplace, but rather the overlay dir would most likely be it's only location. IIRC the reason for /usr/portage/local/ was to have a path within the portage tree that rsync wouldn't kill; given that what you're suggesting is already not under the proposed portage tree location, emerge --sync couldn't touch it, and so I don't see a need at all to provide a 'local' repository destination by default. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDTNlQACgkQ2ugaI38ACPCxQAEApT/7CaIbuVTwnDQk93hhDjGu mXKPdCJg4h1iMECtdoABAJj2601LuRPUKFJ+BJa/FqrdRTsjSpBRiEd8pvO2042P =W3T9 -END PGP SIGNATURE-
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, 2012-12-20 at 09:11 +0100, Ulrich Mueller wrote:
> > On Wed, 19 Dec 2012, Brian Dolbec wrote:
>
> > just to clarify, I'm voting for...
>
> > /var/cache/distfiles
> > /var/cache/packages
>
> Fine.
>
> > /var/cache/repositories/
> > /var/cache/repositories/gentoo <== the main portage tree
> > /var/cache/repositories/local<== the new location for a local overlay
> > /var/cache/repositories/some-overlay <== layman installed overlay
>
> So the Portage tree would move from the second level (/usr/portage) to
> the fourth level? IMHO this is unacceptable. Make it /var/cache/gentoo
> or /var/cache/portage; the /var/cache directory really isn't so
> overpopulated that there's a need for hiding things in subdirs.
>
> Also I wonder if local overlays should be in /var/cache? It might not
> always be possible to restore them.
>
> Ulrich
>
My idea for having all repos under one directory is to make it easier
for a pkg manager to simply scan the directory to know all installed
overlays. Currently each one has to be listed in a configured variable
in make.conf. So if you wanted your local overlay somewhere else, then
a symlink would work (provided the PM can/will autoscan repos), or add
it to the PORTDIR_OVERLAY variable (current behavior). I don't
otherwise have a strong desire for it to be there.
If and only if the tree and all overlays (not other directories) are not
under one directory, then an autoscan cannot easily happen.
For an example of what I am referring to. In layman-2.0.0 I have added
a /etc/layman/overlays directory. On start it will scan it for any
*.xml files and add those specifications to the overlays variable.
Layman-1.4 and previous required you add each entry to that overlays
variable in layman.cfg. Essentially this makes the overlays directory a
plug-in directory, so if you want to install an overlay not listed in
the main repositories list, just download the xml spec to
/etc/layman/overlays/${meaningful-name}.xml
then layman -f (adds it to it's cache)
no editing required :)
If repositories is too long a name, repos is shorter and still
meaningful, although still puts them at a 4th level.
--
Brian Dolbec
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Moving our/portage stuff to var
Zac Medico writes: > On 12/19/2012 02:01 PM, Alan McKinnon wrote: >> If we are going to move distfiles out of the tree into, what are the >> odds of getting /some/path/portage/local to move somewhere else too? > > What program uses this "local" directory? It's not used directly by > portage itself, though portage has an exclude for it in the default > PORTAGE_RSYNC_OPTS setting (in /usr/share/portage/config/make.globals). It is useful for 'site' local ebuilds. It allows a 'master' repository to sync with the main Gentoo one without disturbing local changes but allow other systems on-site to fetch the modified tree with a simple 'emerge --sync'.
Re: [gentoo-dev] Moving our/portage stuff to var
> On Thu, 20 Dec 2012, Rich Freeman wrote: > I actually like the /var/cache/repositories approach. You can always > add a symlink to it if you want to for convenience (as I already do > for /var/lib/portage/world). There is really nothing special about > /usr/portage, other than it being the lowest-priority overlay. There's also nothing special about Earth amongst other planets, so please add "Earth / Solar System" when addressing your letters. SCNR, Ulrich
Re: [gentoo-dev] Re: eudev project announcement
On 12/20/2012 07:02 AM, Rich Freeman wrote: > On Thu, Dec 20, 2012 at 6:21 AM, Richard Yao wrote: >> No one has proposed moving everything to /usr. At the minimum, we would >> still have /etc and /var in /, as well as various mountpoints. If we do >> move those to /usr, then we effectively renamed / to /usr, which is >> pointless. The absurdity of mounting /usr over NFS instead of / is >> precisely why people are saying to just mount / (with /usr as being part >> of it). > > We're drifting here, but the concept is that machine-local stuff like > configuration stays out of /usr, and generic distro stuff stays in > /usr. > > A webserver for site1 vs site2 would be identical in /usr, but > different elsewhere. > > However, that whole approach makes less sense for a distro that prides > itself on you being able to make every installation unique. That > said, if you do want to make a whole bunch of Gentoo installs the same > then sticking everything important in /usr and network mounting it is > a good way to accomplish it. > > Rich > You could accomplish a similar effect at the NFS server via a stacking filesystem, with the advantage being that all configuration data would be stored remotely. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: eudev project announcement
On Thu, Dec 20, 2012 at 6:21 AM, Richard Yao wrote: > No one has proposed moving everything to /usr. At the minimum, we would > still have /etc and /var in /, as well as various mountpoints. If we do > move those to /usr, then we effectively renamed / to /usr, which is > pointless. The absurdity of mounting /usr over NFS instead of / is > precisely why people are saying to just mount / (with /usr as being part > of it). We're drifting here, but the concept is that machine-local stuff like configuration stays out of /usr, and generic distro stuff stays in /usr. A webserver for site1 vs site2 would be identical in /usr, but different elsewhere. However, that whole approach makes less sense for a distro that prides itself on you being able to make every installation unique. That said, if you do want to make a whole bunch of Gentoo installs the same then sticking everything important in /usr and network mounting it is a good way to accomplish it. Rich
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, Dec 20, 2012 at 4:25 AM, George Shapovalov wrote: > On Thursday 20 December 2012 09:11:39 Ulrich Mueller wrote: >> > /var/cache/repositories/local<== the new location for a local overlay >> >> Also I wonder if local overlays should be in /var/cache? It might not >> always be possible to restore them. > So, this is the present /usr/local/portage? What's wrong with it? > According to FHS, /usr/local/ is reserved for local admin meddling, which fits > the bill rather nicely fo local overlay. This is the one location that was > actually making sense from the beginning. I actually like the /var/cache/repositories approach. You can always add a symlink to it if you want to for convenience (as I already do for /var/lib/portage/world). There is really nothing special about /usr/portage, other than it being the lowest-priority overlay. As far as the local one goes - again this is configurable in /etc/make.conf, and we don't really need to pre-create that directory either. Rich
Re: [gentoo-dev] Moving our/portage stuff to var
On Wed, 19 Dec 2012 14:19:52 -0800
Zac Medico wrote:
> On 12/19/2012 02:01 PM, Alan McKinnon wrote:
> > On Wed, 19 Dec 2012 14:56:44 +0100
> > Diego Elio Pettenò wrote:
> >
> >> Just mv /usr/portage /var/portage ? FFS no. Among other things, as
> >> many said before, we should really take distfiles out of the tree
> >> itself, and packages the same. And I don't want /var/packages
> >> or /var/distfiles at all.
> >
> > If we are going to move distfiles out of the tree into, what are the
> > odds of getting /some/path/portage/local to move somewhere else too?
>
> What program uses this "local" directory? It's not used directly by
> portage itself, though portage has an exclude for it in the default
> PORTAGE_RSYNC_OPTS setting
> (in /usr/share/portage/config/make.globals).
It goes back a long time, and is basically a poor man's local overlay
without having to use layman. As I understand it, portage will treat
the directory like any other when looking for ebuilds and resolving
deps, but exclude it from a sync.
>
> > That one has irked me for ages, its the one thing left on my systems
> > that stops the local tree dir being an exact replica of the upstream
> > master.
>
> For portage's defaults, I won't settle for anything less than having
> them all refer to separate directories which are *not* nested within
> one other. These are the current default settings which violate my
> requirements:
>
> PORTDIR=/usr/portage
> DISTDIR=${PORTDIR}/distfiles
> PKGDIR=${PORTDIR}/packages
> RPMDIR=${PORTDIR}/rpm
/usr/portage/local has the taste feel and smell of a hacky workaround:
shove a directory in the tree and exclude it from sync.
I suspect the best solution all round is to move all support for local
overlays into layman. I'd be happy with that. Probably make the portage
code cleaner too.
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-dev] Re: eudev project announcement
On 12/20/2012 03:31 AM, Michał Górny wrote: > On Thu, 20 Dec 2012 00:27:26 +0100 > "J. Roeleveld" wrote: > >> On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote: >>> On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote: On Mon, December 17, 2012 22:31, Greg KH wrote: > On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: >> Olav Vitters wrote: >>> On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote: As I said in an earlier email, Lennart Poettering claims that it does not work. We are discussing some of the things necessary to make it >>> >>> work. >>> >>> Just to repeat: >>> In this thread it was claimed that a separate /usr is not supported by >>> systemd/udev. >>> >>> A case which works with latest systemd on various distributions. I >>> checked with upstream (not Lennart), and they confirmed it works. I >>> can >>> wait for Lennart to say the same, but really not needed. >>> >>> I assume this will again turn into a "but I meant something else". >> >> Olav. >> >> Lennart has stated that he considers a seperate /usr without init* >> broken. > > Yes, as do I, and so do a lot of other developers. It is only "broken", because upstream decided to move everything into /usr that was previously in /. >>> >>> No, not at all, please see the web page that describes, in detail, the >>> problems that has been going on for quite some time now, with the /usr >>> and / partitions and packages. >>> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken >>> >>> One good solution to this issue is to move everything into /usr, and >>> that's something that has wonderful benifits in the long run, and is >>> something that I expect all Linux distros to eventually implement. >>> Those that don't, will suffer because of it. >>> >>> Again, see the web page for why moving stuff into /usr is a good idea >>> for the reasons behind this. >>> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge >> >> Example: /usr Network Share >> When /usr is on a network share, why not add a / on network as well? >> I have multiple systems and as they all have different uses, they all have >> different software installed. >> >> Example: Multiple Guest Operating Systems on the Same Host >> See answer to previous example. >> >> How many environments actually currently exist where a shared /usr is being >> used? > > Are you aware that these environments are actually one of the most > important reasons for moving everything to /usr? I don't know what > hackery you're using to keep the systems in sync and working but it is > braindead enough. > > The difference between keeping part of the system in rootfs > and initramfs is that you can discard initramfs after using it. It can > be anything which is enough to get the /usr mounted and system > starting. Files on rootfs *have* to be in sync with those on /usr > or you're getting random failures. > No one has proposed moving everything to /usr. At the minimum, we would still have /etc and /var in /, as well as various mountpoints. If we do move those to /usr, then we effectively renamed / to /usr, which is pointless. The absurdity of mounting /usr over NFS instead of / is precisely why people are saying to just mount / (with /usr as being part of it). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving our/portage stuff to var
On Thursday 20 December 2012 09:11:39 Ulrich Mueller wrote: > > /var/cache/repositories/local<== the new location for a local overlay > > Also I wonder if local overlays should be in /var/cache? It might not > always be possible to restore them. So, this is the present /usr/local/portage? What's wrong with it? According to FHS, /usr/local/ is reserved for local admin meddling, which fits the bill rather nicely fo local overlay. This is the one location that was actually making sense from the beginning. Now, trying to recall its history, I seem to remember that it was not there from the onset, but rather added when we first had this idea of overlays, and, faintly (remember), even having some discussion with some technical arguments. I guess this is how it ended up in the place that makes sense :). George
[gentoo-dev] Re: Moving our/portage stuff to var
Ulrich Mueller posted on Thu, 20 Dec 2012 09:11:39 +0100 as excerpted: > Also I wonder if local overlays should be in /var/cache? It might not > always be possible to restore them. Good point. My local overlay's in /usr/local/ (which is a dedicated partition I actually keep several backups of, including my netbook's copy), for exactly that reason. (Actually, /usr/local is a symlink, to a shorter path that's the actual partition, /l, and both PORTDIR and my local overlay are simply "p" (/p being a symlink to the gentoo tree in /usr/src), so I configure and access the overlay as /l/p, and simply /p for the gentoo tree, but the /l partition is also reachable via /usr/local symlink. But however it's identified, the partition reachable as either /l or /usr/local contains the local overlay, and is backed up multiple ways including on an entirely separate machine, which its own copy of the same /l aka /usr/ local.) -- 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
Re: [gentoo-dev] Re: eudev project announcement
On Thu, 20 Dec 2012 00:27:26 +0100 "J. Roeleveld" wrote: > On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote: > > On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote: > > > On Mon, December 17, 2012 22:31, Greg KH wrote: > > > > On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: > > > >> Olav Vitters wrote: > > > >> >On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote: > > > >> >> As I said in an earlier email, Lennart Poettering claims that it > > > >> >> does > > > >> >> not work. We are discussing some of the things necessary to make it > > > >> > > > > >> >work. > > > >> > > > > >> >Just to repeat: > > > >> >In this thread it was claimed that a separate /usr is not supported by > > > >> >systemd/udev. > > > >> > > > > >> >A case which works with latest systemd on various distributions. I > > > >> >checked with upstream (not Lennart), and they confirmed it works. I > > > >> >can > > > >> >wait for Lennart to say the same, but really not needed. > > > >> > > > > >> >I assume this will again turn into a "but I meant something else". > > > >> > > > >> Olav. > > > >> > > > >> Lennart has stated that he considers a seperate /usr without init* > > > >> broken. > > > > > > > > Yes, as do I, and so do a lot of other developers. > > > > > > It is only "broken", because upstream decided to move everything into /usr > > > that was previously in /. > > > > No, not at all, please see the web page that describes, in detail, the > > problems that has been going on for quite some time now, with the /usr > > and / partitions and packages. > > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > > > One good solution to this issue is to move everything into /usr, and > > that's something that has wonderful benifits in the long run, and is > > something that I expect all Linux distros to eventually implement. > > Those that don't, will suffer because of it. > > > > Again, see the web page for why moving stuff into /usr is a good idea > > for the reasons behind this. > > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge > > Example: /usr Network Share > When /usr is on a network share, why not add a / on network as well? > I have multiple systems and as they all have different uses, they all have > different software installed. > > Example: Multiple Guest Operating Systems on the Same Host > See answer to previous example. > > How many environments actually currently exist where a shared /usr is being > used? Are you aware that these environments are actually one of the most important reasons for moving everything to /usr? I don't know what hackery you're using to keep the systems in sync and working but it is braindead enough. The difference between keeping part of the system in rootfs and initramfs is that you can discard initramfs after using it. It can be anything which is enough to get the /usr mounted and system starting. Files on rootfs *have* to be in sync with those on /usr or you're getting random failures. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Moving our/portage stuff to var
> On Wed, 19 Dec 2012, Brian Dolbec wrote: > just to clarify, I'm voting for... > /var/cache/distfiles > /var/cache/packages Fine. > /var/cache/repositories/ > /var/cache/repositories/gentoo <== the main portage tree > /var/cache/repositories/local<== the new location for a local overlay > /var/cache/repositories/some-overlay <== layman installed overlay So the Portage tree would move from the second level (/usr/portage) to the fourth level? IMHO this is unacceptable. Make it /var/cache/gentoo or /var/cache/portage; the /var/cache directory really isn't so overpopulated that there's a need for hiding things in subdirs. Also I wonder if local overlays should be in /var/cache? It might not always be possible to restore them. Ulrich
