[gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1377 bytes --]

Hi all (especially package owners in CC),

In various packages we have inconsistent use of || preferences for
www-client/elinks, links, lynx, w3m, and w3mmee. This means that the
default preference depends on the combination of packages that one has
installed and the order that one has installed them, leading to
unpredictable results.

Here is a list of relevant packages and their dependencies:

app-text/docbook-sgml-utils: || ( www-client/lynx www-client/links
www-client/elinks virtual/w3m )
app-text/sgmltools-lite: || ( www-client/w3m www-client/lynx )
app-text/xmlto: || ( virtual/w3m www-client/lynx www-client/elinks )
dev-lang/mono: || ( www-client/links www-client/lynx )
mail-client/mutt: || ( www-client/lynx www-client/w3m www-client/elinks )
mail-client/neomutt: || ( www-client/lynx www-client/w3m www-client/elinks )
net-irc/irssi: || ( www-client/lynx www-client/elinks )
sys-fs/gt5: || ( www-client/links www-client/elinks www-client/lynx )
x11-base/xorg-server: || ( www-client/links www-client/lynx www-client/w3m )

How about if we create some more virtuals to cover all of the relevant
cases?

We've already got virtual/w3m to cover this particular case:

    || ( www-client/w3m www-client/w3mmee )

We might want to use nested virtuals, in the same way that virtual/jdk
nests under virtual/jre.
-- 
Thanks,
Zac




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

On Sun, 2020-02-09 at 22:30 -0800, Zac Medico wrote:
> Hi all (especially package owners in CC),
> 
> In various packages we have inconsistent use of || preferences for
> www-client/elinks, links, lynx, w3m, and w3mmee. This means that the
> default preference depends on the combination of packages that one has
> installed and the order that one has installed them, leading to
> unpredictable results.
> 
> Here is a list of relevant packages and their dependencies:
> 
> app-text/docbook-sgml-utils: || ( www-client/lynx www-client/links
> www-client/elinks virtual/w3m )
> app-text/sgmltools-lite: || ( www-client/w3m www-client/lynx )
> app-text/xmlto: || ( virtual/w3m www-client/lynx www-client/elinks )
> dev-lang/mono: || ( www-client/links www-client/lynx )
> mail-client/mutt: || ( www-client/lynx www-client/w3m www-client/elinks )
> mail-client/neomutt: || ( www-client/lynx www-client/w3m www-client/elinks )
> net-irc/irssi: || ( www-client/lynx www-client/elinks )
> sys-fs/gt5: || ( www-client/links www-client/elinks www-client/lynx )
> x11-base/xorg-server: || ( www-client/links www-client/lynx www-client/w3m )
> 
> How about if we create some more virtuals to cover all of the relevant
> cases?

I don't think that's a valid case for a virtual since those tools do not
provide a consistent API for other packages.  It just happens that some
packages explicitly support multiple choices, and this is exactly what
|| indicates.

The virtuals would really be arbitrary here.  Developers would
repeatedly fail to use them because they wouldn't naturally expect
the virtual to exist.

> 
> We've already got virtual/w3m to cover this particular case:
> 
>     || ( www-client/w3m www-client/w3mmee )
> 
> We might want to use nested virtuals, in the same way that virtual/jdk
> nests under virtual/jre.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1883 bytes --]

On 2/9/20 10:44 PM, Michał Górny wrote:
> On Sun, 2020-02-09 at 22:30 -0800, Zac Medico wrote:
>> Hi all (especially package owners in CC),
>>
>> In various packages we have inconsistent use of || preferences for
>> www-client/elinks, links, lynx, w3m, and w3mmee. This means that the
>> default preference depends on the combination of packages that one has
>> installed and the order that one has installed them, leading to
>> unpredictable results.
>>
>> Here is a list of relevant packages and their dependencies:
>>
>> app-text/docbook-sgml-utils: || ( www-client/lynx www-client/links
>> www-client/elinks virtual/w3m )
>> app-text/sgmltools-lite: || ( www-client/w3m www-client/lynx )
>> app-text/xmlto: || ( virtual/w3m www-client/lynx www-client/elinks )
>> dev-lang/mono: || ( www-client/links www-client/lynx )
>> mail-client/mutt: || ( www-client/lynx www-client/w3m www-client/elinks )
>> mail-client/neomutt: || ( www-client/lynx www-client/w3m www-client/elinks )
>> net-irc/irssi: || ( www-client/lynx www-client/elinks )
>> sys-fs/gt5: || ( www-client/links www-client/elinks www-client/lynx )
>> x11-base/xorg-server: || ( www-client/links www-client/lynx www-client/w3m )
>>
>> How about if we create some more virtuals to cover all of the relevant
>> cases?
> 
> I don't think that's a valid case for a virtual since those tools do not
> provide a consistent API for other packages.  It just happens that some
> packages explicitly support multiple choices, and this is exactly what
> || indicates.
> 
> The virtuals would really be arbitrary here.  Developers would
> repeatedly fail to use them because they wouldn't naturally expect
> the virtual to exist.

In that case, I suppose we'll have to apply consistency manually? Can we
all agree on a global order of preference for the relevant packages?
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

On Sun, 2020-02-09 at 22:51 -0800, Zac Medico wrote:
> On 2/9/20 10:44 PM, Michał Górny wrote:
> > On Sun, 2020-02-09 at 22:30 -0800, Zac Medico wrote:
> > > Hi all (especially package owners in CC),
> > > 
> > > In various packages we have inconsistent use of || preferences for
> > > www-client/elinks, links, lynx, w3m, and w3mmee. This means that the
> > > default preference depends on the combination of packages that one has
> > > installed and the order that one has installed them, leading to
> > > unpredictable results.
> > > 
> > > Here is a list of relevant packages and their dependencies:
> > > 
> > > app-text/docbook-sgml-utils: || ( www-client/lynx www-client/links
> > > www-client/elinks virtual/w3m )
> > > app-text/sgmltools-lite: || ( www-client/w3m www-client/lynx )
> > > app-text/xmlto: || ( virtual/w3m www-client/lynx www-client/elinks )
> > > dev-lang/mono: || ( www-client/links www-client/lynx )
> > > mail-client/mutt: || ( www-client/lynx www-client/w3m www-client/elinks )
> > > mail-client/neomutt: || ( www-client/lynx www-client/w3m www-client/elinks )
> > > net-irc/irssi: || ( www-client/lynx www-client/elinks )
> > > sys-fs/gt5: || ( www-client/links www-client/elinks www-client/lynx )
> > > x11-base/xorg-server: || ( www-client/links www-client/lynx www-client/w3m )
> > > 
> > > How about if we create some more virtuals to cover all of the relevant
> > > cases?
> > 
> > I don't think that's a valid case for a virtual since those tools do not
> > provide a consistent API for other packages.  It just happens that some
> > packages explicitly support multiple choices, and this is exactly what
> > > > indicates.
> > 
> > The virtuals would really be arbitrary here.  Developers would
> > repeatedly fail to use them because they wouldn't naturally expect
> > the virtual to exist.
> 
> In that case, I suppose we'll have to apply consistency manually? Can we
> all agree on a global order of preference for the relevant packages?

That would be my idea, yes.  I'd suggest going for the 'lightest'
package first.  Would you be able to figure out some kind of measure
on how heavy each of those packages is?  I suppose we need to account
for build time and dependencies.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny <mgorny@gentoo.org>
ha scritto:

> On Sun, 2020-02-09 at 22:51 -0800, Zac Medico wrote:
> > In that case, I suppose we'll have to apply consistency manually? Can we
> > all agree on a global order of preference for the relevant packages?
>
> That would be my idea, yes.  I'd suggest going for the 'lightest'
> package first.  Would you be able to figure out some kind of measure
> on how heavy each of those packages is?  I suppose we need to account
> for build time and dependencies.
>
> All of these packages are pretty old and not receiving commits in years,
may I suggest that the order should be from the less prone to break to the
most prone to break?
I'll leave to maintainers decide on how to assign a vote on resilience, but
monitoring upstream, active forks and other distro should be taken in
account.

Best,
Francesco

[-- Attachment #2: Type: text/html, Size: 1275 bytes --]

Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee

[Joonas Niilola]

[-- Attachment #1.1.1: Type: text/plain, Size: 1131 bytes --]


On 2/11/20 12:32 PM, Francesco Riosa wrote:
>
>
> Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny
> <mgorny@gentoo.org <mailto:mgorny@gentoo.org>> ha scritto:
>
>     On Sun, 2020-02-09 at 22:51 -0800, Zac Medico wrote:
>     > In that case, I suppose we'll have to apply consistency
>     manually? Can we
>     > all agree on a global order of preference for the relevant packages?
>
>     That would be my idea, yes.  I'd suggest going for the 'lightest'
>     package first.  Would you be able to figure out some kind of measure
>     on how heavy each of those packages is?  I suppose we need to account
>     for build time and dependencies.
>
> All of these packages are pretty old and not receiving commits in
> years, may I suggest that the order should be from the less prone to
> break to the most prone to break?

How do you determine this?


> I'll leave to maintainers decide on how to assign a vote on resilience,

Ah. So no.


Whats wrong with simply sorting by alphabetic order? Elinks seems a fine
default for those who don't care enough to change it.


-- juippis


[-- Attachment #1.1.2: Type: text/html, Size: 3119 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 642 bytes --]