As the discussion was raised again on the gentoo-dev ml [1], I'm opening a bug to track any changes related to it. Saying shortly, the problems are: - /usr/portage is not really FHS-y location for a PORTDIR, - storing distfiles & binpackages in PORTDIR subdirs is basically a bad idea (I think we should rather convince users to use separate fs for PORTDIR), - also the 'suggested' PORTDIR_OVERLAY sounds better being inside PORTDIR than outside it (for the sake of having separate fs for it). Distfiles should obviously go to /var/cache. Binpackages are more complicated. PORTDIR sounds /var/cache-y too but unsure if portage could sync it without any additional action. [1]:http://archives.gentoo.org/gentoo-dev/msg_c35325d13ef3c1259449f3a7004da303.xml
In order to ensure that the locations don't unexpectedly change for existing installs, I'd like to run a migration tool during pkg_preinst that will detect when a user has not overridden the default settings of variables like PORTDIR, and will automatically add the old default settings to make.conf.
Isn't CONFIG_PROTECT all about nicely telling users defaults change?
(In reply to comment #2) > Isn't CONFIG_PROTECT all about nicely telling users defaults change? Yes, and I plan for the migration tool to respect CONFIG_PROTECT when it modifies make.conf. If you're thinking about changes to the defaults in make.globals though, that won't be visible via CONFIG_PROTECT, since make.globals has resided in /usr/share/portage/config/ for years now because it's not intended to be modified by users.
(In reply to comment #0) > - storing distfiles & binpackages in PORTDIR subdirs is basically a bad idea (I > think we should rather convince users to use separate fs for PORTDIR), Could you provide a linked or inlined rationale? > Distfiles should obviously go to /var/cache. Binpackages are more complicated. > PORTDIR sounds /var/cache-y too but unsure if portage could sync it without any > additional action. PORTDIR (and PORTDIR_OVERLAY) -- as a remote cache -- is no true cache in the sense of FHS: I see these two points of FSH for /var/cache violated: 1) "The application must be able to regenerate or restore the data." 2) "[T]he cached files can be deleted without data loss." (1) may fail when ebuilds get deleted (please save me a discussion on how version control makes up for that or not), (2) fails on failure of (1). For that reason, layman's home moved to /var/lib/ last time, instead of /var/cache: it is currently located at /var/lib/layman/.
(In reply to comment #4) > (In reply to comment #0) > > - storing distfiles & binpackages in PORTDIR subdirs is basically a bad idea (I > > think we should rather convince users to use separate fs for PORTDIR), > > Could you provide a linked or inlined rationale? You pasted the rationale below. PORTDIR is a lot of often-changing, small files which can be regenerated with some effort on user side. Distfiles are random size files which can be removed at a random point in time. > > Distfiles should obviously go to /var/cache. Binpackages are more complicated. > > PORTDIR sounds /var/cache-y too but unsure if portage could sync it without any > > additional action. > > PORTDIR (and PORTDIR_OVERLAY) -- as a remote cache -- is no true cache in the > sense of FHS: I see these two points of FSH for /var/cache violated: > > 1) "The application must be able to regenerate or restore the data." > > 2) "[T]he cached files can be deleted without data loss." > > (1) may fail when ebuilds get deleted (please save me a discussion on how > version control makes up for that or not), (2) fails on failure of (1). (1) is what I mentioned, (2) makes /var/cache a completely bad choice indeed.
(In reply to comment #3) > (In reply to comment #2) > > Isn't CONFIG_PROTECT all about nicely telling users defaults change? > > Yes, and I plan for the migration tool to respect CONFIG_PROTECT when it > modifies make.conf. If you're thinking about changes to the defaults in > make.globals though, that won't be visible via CONFIG_PROTECT, since > make.globals has resided in /usr/share/portage/config/ for years now because > it's not intended to be modified by users. There is a symlink in /etc/make.globals, shouldn't we remove that also then? What about /etc/make.profile and /etc/make.conf, should they be moved under /etc/portage?
(In reply to comment #6) > There is a symlink in /etc/make.globals, shouldn't we remove that also then? We can. It's only there for backward compatibility people who source it from scripts. > What about /etc/make.profile and /etc/make.conf, should they be moved under > /etc/portage? It's already been supported for some time now. There's support for /etc/portage/make.profile in eselect-profile too.
(In reply to comment #4) > (In reply to comment #0) > > Distfiles should obviously go to /var/cache. Binpackages are more complicated. > > PORTDIR sounds /var/cache-y too but unsure if portage could sync it without any > > additional action. Yes it can, just point your portdir in your make.conf somewhere else then do emerge --sync and you will create a complete portdir. > > PORTDIR (and PORTDIR_OVERLAY) -- as a remote cache -- is no true cache in the > sense of FHS: I see these two points of FSH for /var/cache violated: > > 1) "The application must be able to regenerate or restore the data." How can portage not do this? as I said above, that's what emerge --sync does. > 2) "[T]he cached files can be deleted without data loss." They can, just use emerge --sync to get portdir back and or emerge -f to get distfiles back. > > (1) may fail when ebuilds get deleted (please save me a discussion on how > version control makes up for that or not), (2) fails on failure of (1). Given my comments above, I do not see how either of these fail. > For that reason, layman's home moved to /var/lib/ last time, instead of > /var/cache: it is currently located at /var/lib/layman/. From the definition of /var/lib in the fhs: "This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation." I think portdir and distfiles cannot go in /var/lib because anything in /var/lib must not be shared between different computers, and I have heard of folks sharing portdir and distfiles. I think /var/cache is the best place for this. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
(In reply to comment #8) > > PORTDIR (and PORTDIR_OVERLAY) -- as a remote cache -- is no true cache in the > > sense of FHS: I see these two points of FSH for /var/cache violated: > > > > 1) "The application must be able to regenerate or restore the data." > > How can portage not do this? as I said above, that's what emerge --sync does. > > > 2) "[T]he cached files can be deleted without data loss." > > They can, just use emerge --sync to get portdir back and or emerge -f to get > distfiles back. That's not exactly that. It is rather that a random files inside /var/cache can disappear for no reason, and portage would have to be able to re-get them live, e.g. when performing @world update. Although this is possible to implement, it would mean an increase in bandwidth (as portage would have to ping rsync over and over again) and real pain for users. Not really worth it. > > (1) may fail when ebuilds get deleted (please save me a discussion on how > > version control makes up for that or not), (2) fails on failure of (1). > > Given my comments above, I do not see how either of these fail. It fails if user doesn't know he/she has to do --sync because a random file has been removed. > > For that reason, layman's home moved to /var/lib/ last time, instead of > > /var/cache: it is currently located at /var/lib/layman/. > > From the definition of /var/lib in the fhs: > > "This hierarchy holds state information pertaining to an application or the > system. State information is data that programs modify while they run, and that > pertains to one specific host. Users must never need to modify files in > /var/lib to configure a package's operation." > > I think portdir and distfiles cannot go in /var/lib because anything in > /var/lib must not be shared between different computers, and I have heard of > folks sharing portdir and distfiles. PORTDIR may stay in /usr but would have to go to some nice, clean subdir. Probably /usr/local/share or */lib, sth like that. > [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
(In reply to comment #8) > I think portdir and distfiles cannot go in /var/lib because anything in > /var/lib must not be shared between different computers, and I have heard of > folks sharing portdir and distfiles. > > I think /var/cache is the best place for this. Good point. Just /var/cache doesn't seem a logical consequence to me. > > > 2) "[T]he cached files can be deleted without data loss." > > > > They can, just use emerge --sync to get portdir back and or emerge -f to get > > distfiles back. > > That's not exactly that. It is rather that a random files inside /var/cache can > disappear for no reason, and portage would have to be able to re-get them live, > e.g. when performing @world update. To be very clear: my point is on avoiding loss of data, not just on the trouble and time re-creation could take in a good case. > PORTDIR may stay in /usr but would have to go to some nice, clean subdir. > Probably /usr/local/share or */lib, sth like that. I wonder: what advantage does /usr/local/share give over plain /usr/share ? According to FHS 2.3 [1] our ebuilds tree would qualify for being architecture independent because both a sparc and amd64 maschine could share that mount. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA Unfortunately, one problem is that program app-misc/gentoo (a file manager) installs to files /usr/share/gentoo/. With my puristic hat on I would say that /usr/local/share/gentoo/ inherits too much of that problem. On another one: would /opt be an alternative? Inside /opt there seem few restrictions, we could either use /opt/portage (if we aim at minimal changes felt) or something like this for a more thorough switch: - /opt/gentoo/tree/gentoo # PORTDIR - /opt/gentoo/tree/betagarden - /opt/gentoo/tree/sunrise - /opt/gentoo/distfiles/ As a side effect, this scheme could would (1) force less portage branding on other package managers and (2) help getting rid of the mis-use of "portage" for "the gentoo main tree" (and leave that term it to the piece of software, only). But maybe someone comes up with something better yet, I'm curious.
(In reply to comment #10) > > PORTDIR may stay in /usr but would have to go to some nice, clean subdir. > > Probably /usr/local/share or */lib, sth like that. > > I wonder: what advantage does /usr/local/share give over plain /usr/share ? Files not controlled by PM should go into /usr/local. And by 'controlled' I mean recorded in vdb. Of course, most of our eselect thingies break that rule. > Unfortunately, one problem is that program app-misc/gentoo (a file manager) > installs to files /usr/share/gentoo/. With my puristic hat on I would say that > /usr/local/share/gentoo/ inherits too much of that problem. It's just about choosing the right name. > On another one: would /opt be an alternative? Inside /opt there seem few > restrictions, we could either use /opt/portage (if we aim at minimal changes > felt) or something like this for a more thorough switch: > - /opt/gentoo/tree/gentoo # PORTDIR > - /opt/gentoo/tree/betagarden > - /opt/gentoo/tree/sunrise > - /opt/gentoo/distfiles/ I'd personally like to get rid of /opt. We're mis-using it completely and it's just another directory outside of /usr which can grow ridiculously large for no good reason. > As a side effect, this scheme could would (1) force less portage branding on > other package managers and (2) help getting rid of the mis-use of "portage" for > "the gentoo main tree" (and leave that term it to the piece of software, only). Other schemes can do that as well.
(In reply to comment #9) > PORTDIR may stay in /usr but would have to go to some nice, clean subdir. FHS defines /usr as: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." The entire reason for this discussion is to get these directories out of /usr. > Probably /usr/local/share or */lib, sth like that. /usr/local is defined as: "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr." So we should not attempt to put portdir or any of these directories there. (In reply to comment #10) > (In reply to comment #8) > > > > 2) "[T]he cached files can be deleted without data loss." > > > > > > They can, just use emerge --sync to get portdir back and or emerge -f to get > > > distfiles back. > > > > That's not exactly that. It is rather that a random files inside /var/cache can > > disappear for no reason, and portage would have to be able to re-get them live, > > e.g. when performing @world update. The worst that would happen if an individual ebuild disappeared is that a downgrade might be triggered. But, again, if the user does an emerge --sync, this would be reversed. If something in distfiles disappears, it will be downloaded again when the user updates the package. > To be very clear: my point is on avoiding loss of data, not just on the trouble > and time re-creation could take in a good case. I'm still not understanding you. I don't see where the data loss that you are wanting to avoid would occur
Maybe it's about the fact that all these "recovery" steps need the system being online. I can imagine that there are quite some Gentoo users who don't have permanent access to the internet. So for these users loosing data in ${PORTDIR} or ${DISTDIR} could prevent clean emerges at the worst until the can go online again.
Right. In the case of PORTDIR_OVERLAY, ebuils may get lost into nowhere because a repo goes 404 or a forced push wipes away ebuilds that I need to restore a certain defined state of my system. Maybe I need that very version of that very outdated non-standard tool. If there was an ebuild before, there is loss after.
(In reply to comment #12) > (In reply to comment #9) > > PORTDIR may stay in /usr but would have to go to some nice, clean subdir. > > FHS defines /usr as: > > "/usr is the second major section of the filesystem. /usr is shareable, > read-only data. That means that /usr should be shareable between various > FHS-compliant hosts and must not be written to. Any information that is > host-specific or varies with time is stored elsewhere." > > The entire reason for this discussion is to get these directories out of /usr. If we could find a clear location for repositories in /usr, these could be shared nicely. > > Probably /usr/local/share or */lib, sth like that. > > /usr/local is defined as: > > "The /usr/local hierarchy is for use by the system administrator when > installing software locally. It needs to be safe from being overwritten when > the system software is updated. It may be used for programs and data that are > shareable amongst a group of hosts, but not found in /usr." > > So we should not attempt to put portdir or any of these directories there. I agree. > (In reply to comment #10) > > (In reply to comment #8) > > > > > 2) "[T]he cached files can be deleted without data loss." > > > > > > > > They can, just use emerge --sync to get portdir back and or emerge -f to get > > > > distfiles back. > > > > > > That's not exactly that. It is rather that a random files inside /var/cache can > > > disappear for no reason, and portage would have to be able to re-get them live, > > > e.g. when performing @world update. > > The worst that would happen if an individual ebuild disappeared is that a > downgrade might be triggered. But, again, if the user does an emerge --sync, > this would be reversed. This is much like a HTTP proxy showing 'hey, this page has been removed from cache. Please open the following link to refetch it.'
(In reply to comment #15) > (In reply to comment #12) > > (In reply to comment #9) > > > PORTDIR may stay in /usr but would have to go to some nice, clean subdir. > > > > FHS defines /usr as: > > > > "/usr is the second major section of the filesystem. /usr is shareable, > > read-only data. That means that /usr should be shareable between various > > FHS-compliant hosts and must not be written to. Any information that is > > host-specific or varies with time is stored elsewhere." > > > > The entire reason for this discussion is to get these directories out of /usr. > > If we could find a clear location for repositories in /usr, these could be > shared nicely. Please take a look at the definition of /usr above again. In particular, notice that /usr is sharable, read-only data. Later in the definition, it is echoed again that /usr must not be written to. /usr/portage is the wrong place for these repositories for that reason; we need to get them out of /usr. That is why we have this bug.
(In reply to comment #16) > Please take a look at the definition of /usr above again. In particular, notice > that /usr is sharable, read-only data. Later in the definition, it is echoed > again that /usr must not be written to. > > /usr/portage is the wrong place for these repositories for that reason; we need > to get them out of /usr. That is why we have this bug. With that strict assumption, /usr would never be populated. The idea is that user should not write to /usr directly (except for /usr/local) while the PM can do it. Considering that repo-syncing is mostly done by PM (or layman), I guess it's acceptable even if done with limited user privileges. Syncs are done near @world updates. If user wants to do a world update, he/she needs to have /usr r/w anyway.
(In reply to comment #16) > [N]otice that /usr is sharable, read-only data. No contradictions to our case - I agree with mgorny. > /usr/portage is the wrong place for these repositories for that reason; we need > to get them out of /usr. That is why we have this bug. I thought we have it because FHS would not allow adding new dirs right into "/usr", e.g. "/usr/portage".
We could have catalyst write the new defaults in the make.conf that it generates. Having the new defaults explicitly recorded there does not require any changes to portage (though I will bring portage's internal defaults into sync as soon as possible). Also, I think it might help avoid confusion for users if they are able to see the new defaults explicitly recorded in make.conf (as opposed to /usr/share/portage/config/make.globals which is somewhat obscure).
*** Bug 498870 has been marked as a duplicate of this bug. ***
Just as an update. Catalyst's old poor code has been the hold up for migrating these directories to new defaults. I am starting the process now of merging the 3.0 rewrite code back into the master branch. With that it removes the hard coded paths form the code which prevented the defaults from changing. I would think it will take 3 - 4 months to get a new release stabilized and producing new stages with the new defaults (wherever they end up). Who knows, perhaps it will be sooner if I can help it. There is still lots more rewriting to do in catalyst. But I think we can get a decently stable version out within a few months, then do some additional testing/debugging before continuing the rewrites.
I've recently become interested in this topic (the location of the portage tree), as I always thought that /usr/portage was an awkward place for it, and I am happy to see that the devs are reaching an agreement that /var makes a lot more sense. So, what are the current locations preferred by the devs of where to put the portage directories at the moment? I noticed that portage started to complain if PORTDIR wasn't explicitly set in make.conf, so I assume this is going somewhere in the near future. I read some of the old discussions on the topic, and I think that the /var/cache approach is the most appropriate. In particular, I decided to use the following in my systems: PORTDIR=/var/cache/portage/tree DISTDIR=/var/cache/portage/distfiles PKGDIR=/var/cache/portage/packages Also, I don't use any overlays, but I think that /var/cache/portage/overlays or /var/lib/portage/overlays would be a nice location, so one would have their local overlay at /var/lib/portage/overlays/local instead of /usr/local/portage for example (which would also avoid confusion with /usr/portage/local and loss of data). Other overlays would be subdirectories of /var/lib/portage/overlays as well. What do you guys think?
I've read the entire thread entitled "Moving our/portage stuff to var" from the gentoo-dev discussion list in 2012, and I've read all the comments on this bug report, and I would now like to summarize the arguments and give my opinions. 1. Shortness of paths (for ease of typing) seems to be a high priority for certain individuals. To them I say, create some symlinks on your system if you like. Let's not eschew a logical containment hierarchy in favor of laziness. 2. Are sync'd ebuild repositories "cache"? There are good arguments on both sides. * Yes, sync'd ebuild repositories are cache: - * They need not be backed up. - * They can be repopulated with a single command invocation. * No, sync'd ebuild repositories are not cache: - * They cannot be repopulated without an Internet connection. (FHS requires that cache be "locally generated.") - * Arbitrarily deleted files are not automatically regenerated by the application. (An explicit sync must be invoked.) My opinion: The usual intent of a cache dir is to memoize an application's computed results to save time when the same results are needed again in the future. Cache dirs are typically populated in the due course of an application's performing its work, not by explicit request of the user. For this reason, I believe ebuild repositories do *not* belong in /var/cache. There is in fact no FHS-approved location for "system-wide, architecture-independent, shareable data files, fetched/synchronized from the network by a system application only upon user request." We can either invent something or just reuse "/var/db". 3. Are distfiles "cache"? * Yes, distfiles are cache: - * They need not be backed up. - * They are automatically (re)populated as needed. * No, distfiles are not cache: - * They cannot be repopulated without an Internet connection. - * Fetch-restricted distfiles are not automatically repopulated. - * Very old distfiles may no longer be available for download from the mirrors. My opinion: Unlike ebuilds, distfiles are automatically populated by Portage in the due course of its activities. Individual distfiles can be deleted, and they will be automatically replaced as needed. This is very much the expected operation of a cache. Continuous Internet connectivity is already nearly ubiquitous and is becoming more so over time, so I'm inclined to disregard FHS's "locally generated" requirement. N.B.: Fetch-restricted distfiles can be placed in ${PORTAGE_RO_DISTDIR} if the user wishes to treat them as "not cache." 4. Should the master Portage tree be at the same depth as the overlays? * Yes: - * The master Portage tree is simply the lowest-priority "overlay." - * In the new(ish) "repos.conf" configuration, the concept of "overlays" as distinct from ebuild repositories is disappearing. Really, the master Gentoo repository is just another ebuild repository. - * The root of each repository should be a directory whose name matches the repo name. * No: - * A stable system, out of the box, will have only the master Gentoo repository. - * The main Portage tree has historically been "special" — but this is no longer strictly the case; repositories can specify a master other than "gentoo". - * Catalyst will have a problem if the main tree is not in a directory named "portage". My opinion: The master Gentoo repository is simply an ebuild repository, and thus it should be contained in a directory containing only ebuild repositories. The name of the parent directory containing these repositories should be "repos" (not "repositories"), to agree with "/etc/portage/repos.conf". N.B.: Catalyst needs to be fixed. Conclusions: * /var/cache/portage/{distfiles,packages} * /var/db/portage/repos/{gentoo,local,sunrise,kde,…} Optional symlinks (for those who like shorter paths or need backward compatibility): * /usr/portage -> /var/db/portage/repos/gentoo * /usr/local/portage -> /var/db/portage/repos/local
From https://projects.gentoo.org/council/meeting-logs/20180729-summary.txt: > Default locations for repositories, distfiles, and binpkgs > ========================================================== > There was a brief discussion about the color of /var/db vs /var/lib, > and if /var/cache is suitable for binary packages. > > - Vote: Default locations for the Gentoo repository, distfiles, and > binary packages will be, respectively: > /var/db/repos/gentoo > /var/cache/distfiles > /var/cache/binpkgs > Accepted with 6 yes votes and 1 no vote. > > - Vote: Change the name of the Gentoo repository snapshot (currently > portage-YYYYMMDD) to gentoo-YYYYMMDD. > Accepted unanimously.
(In reply to Zac Medico from comment #24) > > - Vote: Default locations for the Gentoo repository, distfiles, and > > binary packages will be, respectively: > > /var/db/repos/gentoo > > /var/cache/distfiles > > /var/cache/binpkgs > > Accepted with 6 yes votes and 1 no vote. Hallelujah! It's interesting that none of the new paths contain the word "portage". Is Gentoo setting up to distance itself from this venerable but crusty package manager? FWIW, I've been using these paths since Comment #23: /var/db/portage/repos/gentoo /var/cache/portage/distfiles /var/cache/portage/packages So the new paths are almost identical except for dropping the "portage" level, which I'm fine to do. Amazing to see this "bug" finally addressed after 7 years. Congratulations to everyone involved.
(In reply to Matt Whitlock from comment #25) > (In reply to Zac Medico from comment #24) > > > - Vote: Default locations for the Gentoo repository, distfiles, and > > > binary packages will be, respectively: > > > /var/db/repos/gentoo > > > /var/cache/distfiles > > > /var/cache/binpkgs > > > Accepted with 6 yes votes and 1 no vote. > > Hallelujah! It's interesting that none of the new paths contain the word > "portage". Is Gentoo setting up to distance itself from this venerable but > crusty package manager? Yeah the idea is that portage is just one implementation of PMS: https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification > FWIW, I've been using these paths since Comment #23: > > /var/db/portage/repos/gentoo > /var/cache/portage/distfiles > /var/cache/portage/packages > > So the new paths are almost identical except for dropping the "portage" > level, which I'm fine to do. > > Amazing to see this "bug" finally addressed after 7 years. Congratulations > to everyone involved. Yeah it's hard to reach a consensus for this sort of thing, so there needed to be a generally agreeable proposal for the council to vote on.
Patches posted for review: https://archives.gentoo.org/gentoo-portage-dev/message/b3ab5ef2895c78c64bea296652f18c69 https://github.com/gentoo/portage/pull/351
Any progress here?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0c25fce6a579216092e321b33ca7d529df59eb56 commit 0c25fce6a579216092e321b33ca7d529df59eb56 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-04-19 04:43:12 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-04-19 04:46:57 +0000 sys-apps/portage: version bump to 2.3.64 Bug 378603 - New (council approved) default locations for the Gentoo repository, distfiles, and binary packages (does not apply to installed systems using the old defaults): /usr/portage -> /var/db/repos/gentoo /usr/portage/distfiles -> /var/cache/distfiles /usr/portage/packages -> /var/cache/binpkgs Bug: https://bugs.gentoo.org/378603 Bug: https://bugs.gentoo.org/683434 Package-Manager: Portage-2.3.64, Repoman-2.3.12 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.64.ebuild | 258 +++++++++++++++++++++++++++++++++ 2 files changed, 259 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1471339d008bb42ce9b727ad0bf7aa354797d712 commit 1471339d008bb42ce9b727ad0bf7aa354797d712 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-04-19 04:49:57 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-04-19 04:50:19 +0000 sys-apps/portage: update 9999 with backward compat for bug 378603 Bug: https://bugs.gentoo.org/378603 Package-Manager: Portage-2.3.64, Repoman-2.3.12 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/portage-9999.ebuild | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=a859556ffaa4b3f55123215a269228f2ef89ee21 commit a859556ffaa4b3f55123215a269228f2ef89ee21 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-08-06 00:07:35 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-04-18 17:52:54 +0000 Update /usr/portage references (bug 378603) Update all relevant references in docs, messages, and comments to refer to /var/db/repos/gentoo instead of /usr/portage. Also update DISTDIR and PKGDIR references to refer to the new /var/cache/{distfiles,binpkgs} locations. Bug: https://bugs.gentoo.org/378603 Signed-off-by: Zac Medico <zmedico@gentoo.org> cnf/make.conf.example | 16 +++++------- lib/portage/__init__.py | 6 ++--- lib/portage/cache/flat_hash.py | 4 +-- lib/portage/tests/news/test_NewsItem.py | 4 +-- lib/portage/tests/resolver/ResolverPlayground.py | 4 +-- lib/portage/xml/metadata.py | 6 ++--- man/ebuild.5 | 9 ++++--- man/emerge.1 | 8 +++--- man/make.conf.5 | 26 ++++++++----------- man/portage.5 | 32 ++++++++++++------------ man/quickpkg.1 | 4 +-- repoman/lib/repoman/__init__.py | 4 +-- 12 files changed, 57 insertions(+), 66 deletions(-) https://gitweb.gentoo.org/proj/portage.git/commit/?id=ef8469befbd7b61f1bae8f21ffd95e0c0306a4f8 commit ef8469befbd7b61f1bae8f21ffd95e0c0306a4f8 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-08-05 21:30:57 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-04-18 17:52:54 +0000 Change /usr/portage council approved locations (bug 378603) This includes a _compat_upgrade.default_locations script that the ebuild can call in pkg_preinst in order to maintain backward-compatible defaults when appropriate. The new defaults are specified in the summary of the 20180729 council meeting: Vote: Default locations for the Gentoo repository, distfiles, and binary packages will be, respectively: /var/db/repos/gentoo /var/cache/distfiles /var/cache/binpkgs Accepted with 6 yes votes and 1 no vote. See: https://projects.gentoo.org/council/meeting-logs/20180729-summary.txt Bug: https://bugs.gentoo.org/378603 Signed-off-by: Zac Medico <zmedico@gentoo.org> cnf/make.globals | 4 +- cnf/repos.conf | 2 +- lib/portage/_compat_upgrade/__init__.py | 0 lib/portage/_compat_upgrade/default_locations.py | 82 ++++++++++++++++++++++++ 4 files changed, 85 insertions(+), 3 deletions(-)
In make.conf.example: # will protect the default locations of DISTDIR and PKGDIR, but users are # warned that any other locations inside PORTDIR are not necessarily safe # for data storage. This passage no longer makes sense, as the default locations of DISTDIR and PKGDIR are not within the default location of PORTDIR. For that matter, should PORTDIR still be described at all? Hasn't it been replaced by repos.conf?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=cde445abb6d3bcc357355589c4d6d9365069d247 commit cde445abb6d3bcc357355589c4d6d9365069d247 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-04-19 05:14:57 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-04-19 05:16:10 +0000 cnf/make.conf.example: remove comment about DISTDIR and PKGDIR in PORTDIR Reported-by: Matt Whitlock <gentoo@mattwhitlock.name> Bug: https://bugs.gentoo.org/378603#c32 Signed-off-by: Zac Medico <zmedico@gentoo.org> cnf/make.conf.example | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
(In reply to Matt Whitlock from comment #32) > For that matter, should PORTDIR still be described at all? Hasn't it been > replaced by repos.conf? It's still supported. We'll have to make sure that catalyst (stage builder) works without it before we drop support entirely.
(In reply to Zac Medico from comment #34) > (In reply to Matt Whitlock from comment #32) > > For that matter, should PORTDIR still be described at all? Hasn't it been > > replaced by repos.conf? > > It's still supported. We'll have to make sure that catalyst (stage builder) > works without it before we drop support entirely. I see that catalyst still uses PORTDIR as seen here: https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=c52962b6bd2e12dec9fdaea6592d39bedce0a752 The code has moved around and it's here now: https://gitweb.gentoo.org/proj/catalyst.git/tree/catalyst/base/stagebase.py?h=3.0.4#n1171
Filed bug 684908 for catalyst.