[gentoo-dev] Re: News Item: Portage Dynamic Deps
> On Wed, 24 Jan 2018, Martin Vaeth wrote: > Ulrich Muellerwrote: >> "Runtime dependencies (RDEPEND). These must be installed and usable >> before the results of an ebuild merging are treated as usable." >> https://projects.gentoo.org/pms/6/pms.html#x1-770008.1 >> >> IMHO this implies that the dependencies at merge time are the >> relevant ones > IMHO this specifies what is relevant when an emerge merging happens. > Nothing more, nothing less. Exactly. RDEPEND is to be evaluated at the time before the package is merged. For PDEPEND it is even clearer: "These must be installed at some point before the package manager finishes the batch of installs." > _If_ one would be willing to interpret it to have a meaning also > _after_ the emerge, then of course the RDEPEND in PMS can refer to > the only value which is specified in PMS, i.e. that stored in the > ebuild ... at the time when the package was merged. You cannot rely on anything else, because the ebuild may be gone in the meantime. > (and not in any database which is explicitly not specified by PMS). > In other words: _If_ one puts any unsaid interpretation into that > sentence, then this can only be dynamic deps. No. The only thing that PMS doesn't specify is the special format of the VDB. However, the spec says that variables must keep their values between phase functions, which includes pkg_prerm() and pkg_postrm(). By this, *some* sort of storage mechanism must exist. Ulrich pgpgC4EFl2XHz.pgp Description: PGP signature
[gentoo-dev] Re: News Item: Portage Dynamic Deps
Ulrich Muellerwrote: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --pgp+signed++Zg8D+I6sgRUw0D > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > >> On Wed, 24 Jan 2018, Martin Vaeth wrote: > >> Rich Freeman wrote: >>> >>> It would already be broken on any PMS-compliant package manager > >> No, it is solely the interpretation of the package manager. >> PMS does not specify what information is stored in /var/db >> or how that information is used. > > "Runtime dependencies (RDEPEND). These must be installed and usable > before the results of an ebuild merging are treated as usable." > https://projects.gentoo.org/pms/6/pms.html#x1-770008.1 > > IMHO this implies that the dependencies at merge time are the relevant > ones IMHO this specifies what is relevant when an emerge merging happens. Nothing more, nothing less. _If_ one would be willing to interpret it to have a meaning also _after_ the emerge, then of course the RDEPEND in PMS can refer to the only value which is specified in PMS, i.e. that stored in the ebuild (and not in any database which is explicitly not specified by PMS). In other words: _If_ one puts any unsaid interpretation into that sentence, then this can only be dynamic deps.
[gentoo-dev] Re: News Item: Portage Dynamic Deps
> On Wed, 24 Jan 2018, Martin Vaeth wrote: > Rich Freemanwrote: >> >> It would already be broken on any PMS-compliant package manager > No, it is solely the interpretation of the package manager. > PMS does not specify what information is stored in /var/db > or how that information is used. "Runtime dependencies (RDEPEND). These must be installed and usable before the results of an ebuild merging are treated as usable." https://projects.gentoo.org/pms/6/pms.html#x1-770008.1 IMHO this implies that the dependencies at merge time are the relevant ones, but not any later changes to the ebuild. Ulrich pgpBFJdeNNmzj.pgp Description: PGP signature
[gentoo-dev] Re: News Item: Portage Dynamic Deps
Rich Freemanwrote: > > It would already be broken on any PMS-compliant package manager No, it is solely the interpretation of the package manager. PMS does not specify what information is stored in /var/db or how that information is used.
Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps
On Tue, Jan 23, 2018 at 8:40 AM, Michael Palimakawrote: > On 01/24/2018 12:15 AM, Michael Orlitzky wrote: >> On 01/23/2018 07:40 AM, Michael Palimaka wrote: Did you come up with a solution how to handle eclass-generated dependency changes then? >>> >>> No. >>> >>> Bug #641346 was filed for clarification about this, but it just got >>> closed without answering the question or consulting anyone. >>> >>> Now, every time we want to make a minor change we need to revbump half >>> the tree due to a change that has been forced mostly by people not >>> actually involved in any actual ebuild maintenance. >> >> You could always set "--dynamic-deps y" on your machine, and ignore the >> breakage caused to end users (i.e. the situation last week). > > You mean the breakage caused by changing default options without any > consultation or notification? > It would already be broken on any PMS-compliant package manager I imagine. The goal is to make the repo and PMS align so that we're not depending on non-PMS behavior. Either our ebuild policies ought to change, or PMS ought to change. It is dumb to publish a specification and then deliberately do things that break software that follows that specification. -- Rich
[gentoo-dev] Re: News Item: Portage Dynamic Deps
On 01/24/2018 12:15 AM, Michael Orlitzky wrote: > On 01/23/2018 07:40 AM, Michael Palimaka wrote: >>> >>> Did you come up with a solution how to handle eclass-generated dependency >>> changes then? >> >> No. >> >> Bug #641346 was filed for clarification about this, but it just got >> closed without answering the question or consulting anyone. >> >> Now, every time we want to make a minor change we need to revbump half >> the tree due to a change that has been forced mostly by people not >> actually involved in any actual ebuild maintenance. > > You could always set "--dynamic-deps y" on your machine, and ignore the > breakage caused to end users (i.e. the situation last week). You mean the breakage caused by changing default options without any consultation or notification?
Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps
On 01/23/2018 07:40 AM, Michael Palimaka wrote: >> >> Did you come up with a solution how to handle eclass-generated dependency >> changes then? > > No. > > Bug #641346 was filed for clarification about this, but it just got > closed without answering the question or consulting anyone. > > Now, every time we want to make a minor change we need to revbump half > the tree due to a change that has been forced mostly by people not > actually involved in any actual ebuild maintenance. You could always set "--dynamic-deps y" on your machine, and ignore the breakage caused to end users (i.e. the situation last week).
Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps
On Tue, Jan 23, 2018 at 7:40 AM, Michael Palimakawrote: > On 01/22/2018 09:28 PM, Andreas K. Huettel wrote: >> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico: >>> >>> According to Gentoo policy, future ebuild dependency changes need to be >>> accompanied by a revision bump in order to trigger rebuilds for users. >>> Therefore, you should only need to use --changed-deps=y for a single >>> deep @world update. After that, if you encounter installed packages with >>> outdated dependencies in a future deep @world update, then you should >>> report it as a bug. >> >> Did you come up with a solution how to handle eclass-generated dependency >> changes then? > > No. > > Bug #641346 was filed for clarification about this, but it just got > closed without answering the question or consulting anyone. >From the bug: "I don't see the need for anything further before the default behavior can be changed in portage, I'm all for it matching PMS behavior." (More details in the comment.) The question was "I would like to ask Council to state more precisely what needs to be specifically documented before we can stop enabling dynamic-deps in Portage by default." So, the answer to the question appears to be "nothing." That might not be an answer that you like, but it is an answer. I can't vouch for who was or wasn't consulted before it was given. -- Rich
[gentoo-dev] Re: News Item: Portage Dynamic Deps
On 01/22/2018 09:28 PM, Andreas K. Huettel wrote: > Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico: >> >> According to Gentoo policy, future ebuild dependency changes need to be >> accompanied by a revision bump in order to trigger rebuilds for users. >> Therefore, you should only need to use --changed-deps=y for a single >> deep @world update. After that, if you encounter installed packages with >> outdated dependencies in a future deep @world update, then you should >> report it as a bug. > > Did you come up with a solution how to handle eclass-generated dependency > changes then? No. Bug #641346 was filed for clarification about this, but it just got closed without answering the question or consulting anyone. Now, every time we want to make a minor change we need to revbump half the tree due to a change that has been forced mostly by people not actually involved in any actual ebuild maintenance.