> On Mon, 07 Sep 2020, Michael Orlitzky wrote:
> You're missing some context. In October of last year, a QA team member
> broke dependency resolution on a lot of systems by making the same sort
> of change that this patch proposes:
> https://archives.gentoo.org/gentoo-dev/message/64c42804eb4c
On 2020-09-07 08:47, Alessandro Barbieri wrote:
> Being consistent in decision is hard I see.
You're missing some context. In October of last year, a QA team member
broke dependency resolution on a lot of systems by making the same sort
of change that this patch proposes:
https://archives.gentoo.
> On Mon, 07 Sep 2020, Alessandro Barbieri wrote:
> Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha
> scritto:
>> We are talking about the second case here, because the dependency on the
>> virtual is being removed, while the dependency on its provider remains
>> in place (it only
Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha
scritto:
> The devmanual [1] says that a revbump should be done when a new runtime
> dependency is added to an ebuild, but it doesn't say that for removal of
> a dependency.
>
> We are talking about the second case here, because the depend
> On Mon, 07 Sep 2020, Michael Orlitzky wrote:
> On 2020-09-07 08:10, Ulrich Mueller wrote:
>> The devmanual [1] says that a revbump should be done when a new
>> runtime dependency is added to an ebuild, but it doesn't say that for
>> removal of a dependency.
> One dependency is removed, and
On 2020-09-07 08:10, Ulrich Mueller wrote:
>> This has caused dependency resolution problems in the past. The PMS
>> implies a new revision,
>
> PMS says nothing about new revisions or revision bumps:
>
That is indeed what the word "implies" implies.
> The devmanual [1] says that a revbump sho
> On Mon, 07 Sep 2020, Michael Orlitzky wrote:
> On 2020-09-07 02:14, Michał Górny wrote:
>> +
>> +Update all ebuilds not to reference the virtual. Since there is
>> +no urgent need to remove the virtual from user systems
>> +and the resulting rebuilds would be unnecessary, do no
On 2020-09-07 02:14, Michał Górny wrote:
> +
> +Update all ebuilds not to reference the virtual. Since there is
> +no urgent need to remove the virtual from user systems
> +and the resulting rebuilds would be unnecessary, do not bump ebuilds
> +when replacing the dependency.
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 7 Sep 2020 21:39:54 +1200
Kent Fredric wrote:
> On Mon, 7 Sep 2020 08:14:52 +0200
> Michał Górny wrote:
>
> > However, please
> > +do not include it in the package.mask entry as users do
> > not need
> > +to be forced to proactiv
On Mon, 7 Sep 2020 08:14:52 +0200
Michał Górny wrote:
> However, please
> +do not include it in the package.mask entry as users do not need
> +to be forced to proactively unmerge it.
I can think of a utilitarian value of doing this anyway.
Namely, it gives a window during `emerge -uD @
On Mon, 2020-09-07 at 09:46 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 07 Sep 2020, Michał Górny wrote:
> > +
> > +If the virtual is being removed along with its second to last
> > +provider, include the virtual in the last-rites mail. However, please
>
> Maybe write "any of its pr
> On Mon, 07 Sep 2020, Michał Górny wrote:
> +
> +If the virtual is being removed along with its second to last
> +provider, include the virtual in the last-rites mail. However, please
Maybe write "any of its providers" instead of "its second to last
provider"? It is simpler and sti
12 matches
Mail list logo
