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

2020-02-11 Thread Joonas Niilola

On 2/11/20 12:32 PM, Francesco Riosa wrote:
>
>
> Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny
> mailto:mgo...@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



signature.asc
Description: OpenPGP digital signature


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

2020-02-11 Thread Francesco Riosa
Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny 
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


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

2020-02-09 Thread Michał Górny
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



signature.asc
Description: This is a digitally signed message part


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

2020-02-09 Thread Zac Medico
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



signature.asc
Description: OpenPGP digital signature


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

2020-02-09 Thread Michał Górny
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



signature.asc
Description: This is a digitally signed message part


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

2020-02-09 Thread Zac Medico
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





signature.asc
Description: OpenPGP digital signature