[gentoo-dev] Re: News Item: Portage Dynamic Deps

2018-01-24 Thread Ulrich Mueller
> On Wed, 24 Jan 2018, Martin Vaeth wrote:

> Ulrich Mueller  wrote:
>> "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

2018-01-24 Thread Martin Vaeth
Ulrich Mueller  wrote:
> 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

2018-01-24 Thread Ulrich Mueller
> 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, but not any later changes to the ebuild.

Ulrich


pgpBFJdeNNmzj.pgp
Description: PGP signature


[gentoo-dev] Re: News Item: Portage Dynamic Deps

2018-01-24 Thread Martin Vaeth
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.




Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps

2018-01-23 Thread Rich Freeman
On Tue, Jan 23, 2018 at 8:40 AM, Michael Palimaka  wrote:
> 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

2018-01-23 Thread Michael Palimaka
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

2018-01-23 Thread Michael Orlitzky
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

2018-01-23 Thread Rich Freeman
On Tue, Jan 23, 2018 at 7:40 AM, Michael Palimaka  wrote:
> 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

2018-01-23 Thread Michael Palimaka
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.