Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Ciaran McCreesh]

On Thu, 01 Jun 2017 07:00:30 +0200
Michał Górny  wrote:
> > - Have a separate anyvimishthing directory, and make both vim and
> > neovim look there, and only make plugins that have been tested to
> > work with both install to that directory.
> 
> ...and then vimthreesome for things that work with three vim
> implementations?

If that ever happens, which is fairly unlikely, then revisit the
problem then, rather than adding unnecessary complexity now just in
case.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Michał Górny]

On śro, 2017-05-31 at 23:54 +0100, Ciaran McCreesh wrote:
> On Thu, 01 Jun 2017 02:32:24 +0700
> "Vadim A. Misbakh-Soloviov"  wrote:
> > - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
> > the installed files
> > 
> > - patching NeoVim source to include Vim's runtimedirs (incl. "after"
> > dir), // NeoVim upstream highly disagree with such way, if any
> > 
> > - patching VIMRUNTIME environment variable,
> > 
> > - making a wrapper,
> > 
> > - rewrite all the existing ebuilds to take nvim into account and
> > force all newcomers to also take it,
> > 
> > - symlinking a directory,
> > // mostly bad way, since opposite plugin compatibility is not
> > garanteed and users can install nvim-only plugins in the future
> > 
> > - making postinst hook to regenerate content of NeoVim's
> > site-directory (maybe, by symlinking installed vim modules there)
> > 
> > or even:
> > 
> > - making eselect module for user to rule that.
> 
> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.
> 

...and then vimthreesome for things that work with three vim
implementations?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Daniel Campbell]

On 05/31/2017 03:54 PM, Ciaran McCreesh wrote:
> On Thu, 01 Jun 2017 02:32:24 +0700
> "Vadim A. Misbakh-Soloviov"  wrote:
>> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
>> the installed files
>>
>> - patching NeoVim source to include Vim's runtimedirs (incl. "after"
>> dir), // NeoVim upstream highly disagree with such way, if any
>>
>> - patching VIMRUNTIME environment variable,
>>
>> - making a wrapper,
>>
>> - rewrite all the existing ebuilds to take nvim into account and
>> force all newcomers to also take it,
>>
>> - symlinking a directory,
>> // mostly bad way, since opposite plugin compatibility is not
>> garanteed and users can install nvim-only plugins in the future
>>
>> - making postinst hook to regenerate content of NeoVim's
>> site-directory (maybe, by symlinking installed vim modules there)
>>
>> or even:
>>
>> - making eselect module for user to rule that.
> 
> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.
> 

+1, though it's still important to keep nvim- and vim-specific dirs.

A third, common dir cuts down on the work that other solutions would
need. It would also give users a way to check which plugins will work
with 'the other one' too and can use that to decide whether they want to
make the switch. This information can probably be gleaned on their own
with some detective work on the Web, but choosing this path gives the
accidental feature for free.

~zlg

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Kent Fredric]

On Wed, 31 May 2017 23:54:59 +0100
Ciaran McCreesh  wrote:

> - Have a separate anyvimishthing directory, and make both vim and
> neovim look there, and only make plugins that have been tested to work
> with both install to that directory.

+1



pgpmXJgzQwGtk.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] meson.eclass: implement basic cross-compiler support

[Mike Gilbert]

This has been pushed.

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Ciaran McCreesh]

On Thu, 01 Jun 2017 02:32:24 +0700
"Vadim A. Misbakh-Soloviov"  wrote:
> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
> the installed files
> 
> - patching NeoVim source to include Vim's runtimedirs (incl. "after"
> dir), // NeoVim upstream highly disagree with such way, if any
> 
> - patching VIMRUNTIME environment variable,
> 
> - making a wrapper,
> 
> - rewrite all the existing ebuilds to take nvim into account and
> force all newcomers to also take it,
> 
> - symlinking a directory,
> // mostly bad way, since opposite plugin compatibility is not
> garanteed and users can install nvim-only plugins in the future
> 
> - making postinst hook to regenerate content of NeoVim's
> site-directory (maybe, by symlinking installed vim modules there)
> 
> or even:
> 
> - making eselect module for user to rule that.

- Have a separate anyvimishthing directory, and make both vim and
neovim look there, and only make plugins that have been tested to work
with both install to that directory.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Ciaran McCreesh]

On Wed, 31 May 2017 21:02:24 +0200
Michał Górny  wrote:
> No, it can't. That's the whole point. The algorithm must be defined so
> that it is always predictable independently of order

So what's this mysterious algorithm then?

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

[Peter Volkov]

Hi.

On Wed, May 31, 2017 at 10:32 PM, Vadim A. Misbakh-Soloviov 
wrote:
> Currently, we have a situation, that there are two Vim's: "old" one
(vim8) and
> NeoVim... Unfortunately, both of them have different runtimedirs...
>
> ... NeoVim supports Vim's plugins/scripts very well (although I
> didn't find any evidence of the opposite), so it is possible to fix that
> situation by many of "kludge" ways, including:
>
> - patching NeoVim source to include Vim's runtimedirs (incl. "after" dir),
> // NeoVim upstream highly disagree with such way, if any

But what is the reasoning for upstream from this way? If NeoVim supports
vim plugins but not vice versa this looks as a very logical step.

--
Peter.

Re: [gentoo-dev] [rfc] dev-libs/expat[unicode] and dev-libs/libbsd dependency

[Sebastian Pipping]

Hi,


On 31.05.2017 21:16, Michał Górny wrote:
>> How do you evaluate these options:
>>
>>  a) Keep libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE
>>
>>  b) Drop libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE
> 
> Does any other distribution use libexpatu.so? If not, then there's
> probably no point in keeping it.

I found none but CoreOS, which is derived from Gentoo (..).


>>  A) libbsd should be a default-off use dependency
>>   IUSE="libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"
>>
>>  B) libbsd could be a default-on use dependency
>>   IUSE="+libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"
> 
> I'd dare say the feature is 'arc4random', then that should be the name
> of the flag.

Good point.

Best



Sebastian



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [RFC] NeoVim and vim-syntax

[Vadim A. Misbakh-Soloviov]

Currently, we have a situation, that there are two Vim's: "old" one (vim8) and 
NeoVim (for those who do not know: a fork of Vim with much and much more clean 
code, many neat features and so on).

Unfortunately, both of them have different runtimedirs: XDG ones for NeoVim 
and the ones you know for Vim8, while NeoVim is fully compatible with Vim's 
plugins, and epecially with vimscripts (like syntax definitions and ftdetect 
scripts).

On the other side, we have a bunch of packages in the portage tree, that have 
"vim syntax" support (use-flags, or direct vim-syntax packages), or even vim-
plugins.
All of them goes to `/usr/share/vim/vimfiles`, while correct path for NeoVim 
would be `/usr/share/nvim/site` (does not exist at the moment, but nvim checks 
for it).

So, that situation leads to impossibility to get all of that syntax definitions 
and plugins when user uses NeoVim.

As I said above, NeoVim supports Vim's plugins/scripts very well (although I 
didn't find any evidence of the opposite), so it is possible to fix that 
situation by many of "kludge" ways, including:

- implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all the 
installed files

- patching NeoVim source to include Vim's runtimedirs (incl. "after" dir),
// NeoVim upstream highly disagree with such way, if any

- patching VIMRUNTIME environment variable,

- making a wrapper,

- rewrite all the existing ebuilds to take nvim into account and force all 
newcomers to also take it,

- symlinking a directory,
// mostly bad way, since opposite plugin compatibility is not garanteed and 
users can install nvim-only plugins in the future

- making postinst hook to regenerate content of NeoVim's site-directory 
(maybe, by symlinking installed vim modules there)

or even:

- making eselect module for user to rule that.

Although, talking on eselect module, I've two visions of the situation:
a) it can be something like bashcomp module, where users can select which of 
installed vim modules they want to "enable" in NeoVim
or (better, imo) way:
b) it can be something like php module, where portage installs all the stuff 
in the location neither available to Vim nor NeoVim, and users selects which 
modules they enable for either implementation.

Module can be called something like "eselect-vim" or "eselect-vim-modules" 
(?), if any.


For now, I have preview of neither of eselect module variants, nor even 
patches for another "ways". I'd very like to discuss the situation and find a 
better of possible solution first.
Maybe, when (if?) we found such a solution, I'd contribute a PR with it on GH.

--
wbr,
mva

Re: [gentoo-dev] [rfc] dev-libs/expat[unicode] and dev-libs/libbsd dependency

[Michał Górny]

On śro, 2017-05-31 at 14:19 +0200, Sebastian Pipping wrote:
> Hi!
> 
> 
> The next release of dev-libs/expat is not far away and there are two
> things that I would appreciate input with, before the next bump in Gentoo:
> 
> 
> -DXML_UNICODE_WCHAR_T issues and Gentoo/Debian mismatch
> ===
> 
> With USE=unicode, on Gentoo two extra libraries are built:
> 
>  * libexpatu.so (with CPPFLAGS=-DXML_UNICODE)
>  * libexpatw.so (with CPPFLAGS=-DXML_UNICODE_WCHAR_T)
>^
> However, -DXML_UNICODE_WCHAR_T has only ever worked with 2-byte wchar_t,
> while 4-byte wchar_t seems mainstream on Linux (and GCC -fshort-wchar
> would required libc to have the same, if you actually wanted to pass
> those wchar_t strings to wprintf and friends).
> 
> So libexpatw.so in Gentoo is not functional at the moment.
> 
> To make things worse, Debian has libexpatw.so with
> CPPFLAGS=-DXML_UNICODE, which corresponds to current libexpatu.so in
> Gentoo, rather than libexpatw.so.
> 
> 
> How do you evaluate these options:
> 
>  a) Keep libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE
> 
>  b) Drop libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE

Does any other distribution use libexpatu.so? If not, then there's
probably no point in keeping it.

> 
> 
> Depend on dev-libs/libbsd
> =
> 
> The next release is very likely to add (optional but helpful) support
> for arc4random_buf that dev-libs/libbsd provides (especially on systems
> with glibc prior to 2.25) [1].  I wonder if Expat's proximity to @system
> has any strong implications on whether
> 
>  A) libbsd should be a default-off use dependency
>   IUSE="libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"
> 
>  B) libbsd could be a default-on use dependency
>   IUSE="+libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"

I'd dare say the feature is 'arc4random', then that should be the name
of the flag.

>  C) libbsd could even go into DEPEND and RDEPEND directly, or
>   RDEPEND="dev-libs/libbsd"
> 
>  D) libbsd should not become any kind of future dependency of
> dev-libs/expat.
> 

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Michał Górny]

On śro, 2017-05-31 at 19:39 +0200, Alexis Ballier wrote:
> > >  Again, you *need* to process the constraints in order. '!a?
> > > ( b ) !b? ( a )' is not deterministic when none of a and b are
> > > enabled otherwise.  
> > 
> > You can't rely on any particular order of constraints, especially when
> > eclass stacking comes into play. You could try defining some
> > constraint- sorting algorithm but it's going to be complex and it's
> > usefulness will be limited anyway due to various kinds of grouping.
> 
> 
> Better have some order: If half of the above constraint comes from
> ebuild and the other half comes from eclass, then PM might toggle 'a' or
> 'b' depending on the phase of the moon which is specifically what we're
> trying to avoid.

No, it can't. That's the whole point. The algorithm must be defined so
that it is always predictable independently of order (maybe except
the ordering inside ^^, ||, ??) and independently of how it's nested
(i.e. 'a? ( b? ( c ) )' must give the same result as 'b? ( a? ( c ) )').

If you start relying on stuff like ordering, you're one step from making
stuff suddenly fail or change meaning due to minor changes, like sorting
stuff.

> eclass stacking is not a problem: specify if it's append or prepend and
> be done.

What about multiple inherits with guards? Next thing I know, we end up
putting REQUIRED_USE outside guards (like we have to do with
EXPORT_FUNCTIONS now) because you need a specific order, and guards make
it unpredictable.

> Note that if you want to remove the need for an order, you'll need to
> ensure that all orderings of the constraints give the same result. It's
> not sufficient to "only" check all possible inputs.

That's the matter of the algorithm.

> Also, what happens if we applied all the constraints and obtained some
> useflags setting that still fails REQUIRED_USE check ?

It can't happen. If you can apply all the constraints, then implicitly
REQUIRED_USE is satisfied. If you can't apply all the constraints, then
it just fails. Of course, we want to ultimately avoid that case.

> > The point would be: by definition, the solver should be able to touch
> > *any* USE flag. If it can't, it mostly implies that you can't use
> > the automatic solver, and so the case is irrelevant for checking.
> > Attempting to go beyond that is going to give a lot of complexity
> > and most likely kill the whole idea.
> > 
> > One thing we need to worry about are masks. We need to think about
> > them.
> 
> It makes zero difference for any solver if you replace variables
> (useflags) by 'true' or 'false' constants (masked/forced/user-forced
> useflags). It's even simpler actually. Whether the formula is not
> constantly 'true' (ie REQUIRED_USE is useless) or constantly
> 'false' (ie there's no way to solve it) is equivalent to solving SAT.
> We likely don't want that for repoman running on php.
> 

Well, probably yes. We just need to make sure to apply them correctly
in different contexts, to avoid accidentally skipping some constraints.
I think it would be reasonably to assume that:

a. flags masked/forced on LHS of implications (foo?) are evaluated
in place, i.e. either always require RHS or remove it completely:

  foo? ( bar )-> with foo forced, bar is always required
  => we should also force bar

b. flags masked/forced inside ^^, ??, || alter the contents/meaning --
in particular they might replace the whole construct with a single flag
or make it unsolvable:

  ^^ ( foo bar baz ) -> with foo forced, [bar baz] are never allowed
 => we should mask them

  || ( foo bar baz ) -> with foo forced, the constraint can be skipped

c. flags masked/forced otherwise can't be altered:

  foo? ( bar )-> with bar forced, we can skip the constraint.
  -> with bar masked, foo should be masked as well

Does that cover all the contexts?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Wed, 31 May 2017 15:04:52 +0200
Michał Górny  wrote:

> On śro, 2017-05-31 at 10:38 +0200, Alexis Ballier wrote:
> > > > What if I specifically set USE=-bar in make.conf ? Do we really
> > > > want PM to override that without telling me ?
> > > 
> > > Yes. Unless you specifically and explicitly disable that
> > > (globally or for USE=bar), in which case the PM would just reject
> > > to proceed.  
> > 
> > 
> > Then could you please explain how to get the list of useflags the
> > solver is allowed to toggle ? Preferably in a PMS-friendly way (aka
> > no USE=foo emerge). It's not clear to me what this would be and is
> > mandatory for determinism.
> > 
> > Note that most definitions are acceptable, but there must be one.  
> 
> If we *really* want to set this for the users, it would simply be
> a variable defined in make.profile, e.g.:
> 
>   REQUIRED_USE_STRICT="foo bar"
> 
> which would mean the solver is globally forbidden from touching those
> flags, i.e. if the solution would involve touching them, PM must fail
> and request user to manually resolve it.
> 
> However, as far as I'm concerned we'd be good at keeping this purely
> as user configuration, alike FEATURES=i-do-not-want-automatic-solving.

Ok, why not.

> > > > I believe that, from the ebuild POV, the ternary useflag model
> > > > is more appropriate: You have a whole bunch of ways to specify
> > > > useflags with portage (make.conf, package.use, profiles, command
> > > > line, ...). From the ebuild those are collapsed into 'user
> > > > input'. You only have IUSE (with its defaults) and that's what
> > > > the auto-solver should play with: those are the flags that can
> > > > be toggled.
> > > 
> > > I see your point. However, it's merely a preference problem and we
> > > really don't want the constraints to become ternary and/or PM try
> > > to force the reverse solutions. That's an easy way to lose
> > > predictability.  
> > 
> > They're not ternary anymore after processing ebuild: IUSE="foo +bar"
> > means instantiate foo as -foo if not specified, and bar as +bar.
> > The way I see it, ternary model is useful in the sense that the 3rd
> > undefined state is what the solver can toggle, the others are fixed
> > (either by user input or e.g. use.mask).
> > 
> > Basically, I see automatic solving of REQUIRED_USE as dynamic IUSE
> > defaults. But see above, this might not be the best way.  
> 
> I'm lost on what you're trying to achieve here. Maybe give a full run-
> out based on Portage behavior -- i.e. involving all the places USE
> flags can be altered in Portage, and how they're going to affect the
> result. Don't forget about USE_ORDER.

What I'm suggesting is: Flags that can be toggled are the same that
would be affected by IUSE defaults. Others are fixed and the
REQUIRED_USE formula is instantiated & reduced with those values. If
there is a contradiction already, fail hard. If not, apply the
algorithm to determine a set of IUSE defaults that would make it
work. Process the ebuild as if it had those IUSE default.

You seem to be going in another direction which is unclear to me.

[...]
> > > > > Now, this also means that every constraint that can't be
> > > > > solved in this easy fashion is invalid. We want to detect
> > > > > that, and warn the developer. Some of those could be tricky.
> > > > > Simple example:
> > > > > 
> > > > >   foo? ( baz ) bar? ( !baz )
> > > > > 
> > > > > This one is invalid because USE='foo bar' requires both 'baz'
> > > > > and '!baz' as a solution. Remember that we don't want to do
> > > > > any changes besides what's explicitly written there, no
> > > > > guessing.
> > > > 
> > > > Besides that, what makes it invalid ?
> > > 
> > > What makes it invalid is that you can't solve it in a predictable
> > > way.  
> > 
> > You can fail in a predictable way and ebuild writer can adjust it to
> > avoid that.  
> 
> If the point is to process constraints *automatically*, then failing
> is not the desired result. Yes, we can consider that a minor
> issue/warning level but it is still an issue. I named it 'invalid'
> because it prevents the automatic solving from working which is the
> purpose of this whole effort.

Ok. I was assuming we do not want to change anything user-specified.
When I set USE=foo, I want foo, not maybe foo. But why not: As you
noted this can be a PM feature and there's not much to be checked in
that case.

As for how to check that, it is still completely unclear to me if
there'd be anything better than enumerating all the possible inputs.


> >  Again, you *need* to process the constraints in order. '!a?
> > ( b ) !b? ( a )' is not deterministic when none of a and b are
> > enabled otherwise.  
> 
> You can't rely on any particular order of constraints, especially when
> eclass stacking comes into play. You could try defining some
> constraint- sorting algorithm but it's going to be complex and it's
> usefulness will be limited anyway due to various kinds 

[gentoo-dev] Items for Council Agenda, June 11

[Anthony G. Basile]

Hi everyone,

The Gentoo Council will be meeting in two weeks.  If anyone has any
issues we need to discuss, please let me know and I'll put it on the
agenda.  Thanks.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Michał Górny]

On śro, 2017-05-31 at 10:38 +0200, Alexis Ballier wrote:
> > > What if I specifically set USE=-bar in make.conf ? Do we really
> > > want PM to override that without telling me ?  
> > 
> > Yes. Unless you specifically and explicitly disable that (globally or
> > for USE=bar), in which case the PM would just reject to proceed.
> 
> 
> Then could you please explain how to get the list of useflags the
> solver is allowed to toggle ? Preferably in a PMS-friendly way (aka no
> USE=foo emerge). It's not clear to me what this would be and is
> mandatory for determinism.
> 
> Note that most definitions are acceptable, but there must be one.

If we *really* want to set this for the users, it would simply be
a variable defined in make.profile, e.g.:

  REQUIRED_USE_STRICT="foo bar"

which would mean the solver is globally forbidden from touching those
flags, i.e. if the solution would involve touching them, PM must fail
and request user to manually resolve it.

However, as far as I'm concerned we'd be good at keeping this purely as
user configuration, alike FEATURES=i-do-not-want-automatic-solving.

> > > I believe that, from the ebuild POV, the ternary useflag model is
> > > more appropriate: You have a whole bunch of ways to specify
> > > useflags with portage (make.conf, package.use, profiles, command
> > > line, ...). From the ebuild those are collapsed into 'user input'.
> > > You only have IUSE (with its defaults) and that's what the
> > > auto-solver should play with: those are the flags that can be
> > > toggled.  
> > 
> > I see your point. However, it's merely a preference problem and we
> > really don't want the constraints to become ternary and/or PM try to
> > force the reverse solutions. That's an easy way to lose
> > predictability.
> 
> They're not ternary anymore after processing ebuild: IUSE="foo +bar"
> means instantiate foo as -foo if not specified, and bar as +bar.
> The way I see it, ternary model is useful in the sense that the 3rd
> undefined state is what the solver can toggle, the others are fixed
> (either by user input or e.g. use.mask).
> 
> Basically, I see automatic solving of REQUIRED_USE as dynamic IUSE
> defaults. But see above, this might not be the best way.

I'm lost on what you're trying to achieve here. Maybe give a full run-
out based on Portage behavior -- i.e. involving all the places USE flags
can be altered in Portage, and how they're going to affect the result.
Don't forget about USE_ORDER.

> > Besides, I should point out that USE_EXPAND in make.profile
> > and make.conf are strictly binary.
> 
> Last I checked IUSE="+use_expand_foo use_expand_bar" worked just as
> useflags.

I'm talking about FOO="bar baz" form which implies -* for all remaining
values (and does not accept '-flag', unless I'm mistaken).

> 
> > > > Now, this also means that every constraint that can't be solved in
> > > > this easy fashion is invalid. We want to detect that, and warn the
> > > > developer. Some of those could be tricky. Simple example:
> > > > 
> > > >   foo? ( baz ) bar? ( !baz )
> > > > 
> > > > This one is invalid because USE='foo bar' requires both 'baz' and
> > > > '!baz' as a solution. Remember that we don't want to do any
> > > > changes besides what's explicitly written there, no guessing.  
> > > 
> > > Besides that, what makes it invalid ?  
> > 
> > What makes it invalid is that you can't solve it in a predictable way.
> 
> You can fail in a predictable way and ebuild writer can adjust it to
> avoid that.

If the point is to process constraints *automatically*, then failing is
not the desired result. Yes, we can consider that a minor issue/warning
level but it is still an issue. I named it 'invalid' because it prevents
the automatic solving from working which is the purpose of this whole
effort.

>  Again, you *need* to process the constraints in order. '!a?
> ( b ) !b? ( a )' is not deterministic when none of a and b are
> enabled otherwise.

You can't rely on any particular order of constraints, especially when
eclass stacking comes into play. You could try defining some constraint-
sorting algorithm but it's going to be complex and it's usefulness will
be limited anyway due to various kinds of grouping.

> You'll get a message like:
> "
>  The constraint bar? ( !baz )' is violated.
> bar is enabled because $reason (say, make.conf)
> baz is enabled because of the constraint 'foo? ( baz )'
> foo is enabled because $reason
> "

You = user or ebuild author? Because per my proposal, this construct
should result in QA error/warning, telling the ebuild writer to use
predictable constraints.

Of course, we could still accept the ebuild and just fail hard on user
side (alike REQUIRED_USE). But that's really getting out of scope.

> 
> > >  How is it more invalid than '?? ( foo bar )' ?  
> > 
> > This would go into:
> > 
> >   foo? ( !bar )
> 
> Just to be clear: Are you suggesting banning '??' from the syntax or
> simply an internal rewrite 

[gentoo-dev] Re: [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Duncan]

Alexis Ballier posted on Wed, 31 May 2017 09:32:57 +0200 as excerpted:

>> For example:
>> 
>>   foo? ( bar )
>> 
>> would mean 'if you have USE=foo, then USE=bar is enabled as well'. Not
>> 'find some random solution which satisfies this'. In other words, here
>> changing USE=foo into USE=-foo is not an acceptable solution.
> 
> 
> What if I specifically set USE=-bar in make.conf ? Do we really want PM
> to override that without telling me ?

Yes, override (tho the telling me bit would be up to the PM 
implementation and could be as indirect as simply showing the new pulled-
in package in ask/pretend) because USE flags always control options and 
don't disable mandatory requirements, which is what this scenario is 
ultimately describing, even if it's /conditional/ mandatory.

If a user cares enough about not wanting whatever USE=bar pulls in, 
they'll notice the pull-in in ask/pretend and abort the merge, 
investigating and changing config or deciding they don't need that 
package after all, just as they do with mandatory pull-ins now.

As for more direct indications, portage could and I'd expect would 
indicate the USE override the same as it does for profile-masked and new-
version-deleted USE flags now, putting them in parentheses so the user 
knows they no longer apply.  I'm not familiar enough with other PMs to 
know if/how they indicate such things, but I'd imagine they could 
similarly treat it to the way they do masked flags today.  After all, 
it's simply another method of masking, only in this case it's dynamic, by 
the PM at solve time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] [rfc] dev-libs/expat[unicode] and dev-libs/libbsd dependency

[Sebastian Pipping]

Hi!


The next release of dev-libs/expat is not far away and there are two
things that I would appreciate input with, before the next bump in Gentoo:


-DXML_UNICODE_WCHAR_T issues and Gentoo/Debian mismatch
===

With USE=unicode, on Gentoo two extra libraries are built:

 * libexpatu.so (with CPPFLAGS=-DXML_UNICODE)
 * libexpatw.so (with CPPFLAGS=-DXML_UNICODE_WCHAR_T)
   ^
However, -DXML_UNICODE_WCHAR_T has only ever worked with 2-byte wchar_t,
while 4-byte wchar_t seems mainstream on Linux (and GCC -fshort-wchar
would required libc to have the same, if you actually wanted to pass
those wchar_t strings to wprintf and friends).

So libexpatw.so in Gentoo is not functional at the moment.

To make things worse, Debian has libexpatw.so with
CPPFLAGS=-DXML_UNICODE, which corresponds to current libexpatu.so in
Gentoo, rather than libexpatw.so.


How do you evaluate these options:

 a) Keep libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE

 b) Drop libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE


Depend on dev-libs/libbsd
=

The next release is very likely to add (optional but helpful) support
for arc4random_buf that dev-libs/libbsd provides (especially on systems
with glibc prior to 2.25) [1].  I wonder if Expat's proximity to @system
has any strong implications on whether

 A) libbsd should be a default-off use dependency
  IUSE="libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"

 B) libbsd could be a default-on use dependency
  IUSE="+libbsd"  RDEPEND="libbsd? ( dev-libs/libbsd )"

 C) libbsd could even go into DEPEND and RDEPEND directly, or
  RDEPEND="dev-libs/libbsd"

 D) libbsd should not become any kind of future dependency of
dev-libs/expat.


Thanks for your time!

Best



Sebastian


[1] https://github.com/libexpat/libexpat/pull/30

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Wed, 31 May 2017 10:03:12 +0200
Michał Górny  wrote:

> On śro, 2017-05-31 at 09:32 +0200, Alexis Ballier wrote:
> > On Wed, 31 May 2017 08:55:17 +0200
> > Michał Górny  wrote:
> >   
> > > On wto, 2017-05-30 at 20:46 +0200, Alexis Ballier wrote:  
> > > > On Tue, 30 May 2017 20:11:38 +0200
> > > > Michał Górny  wrote:
> > > > [...]
> > > > > > > Of course, we could just validate all the possible cases
> > > > > > > via repoman, and reject the ebuild if there's at least one
> > > > > > > conflict between them. Not sure how to express that
> > > > > > > properly in the spec though. Not sure how it would work
> > > > > > > practically.  
> > > > > > 
> > > > > > Adding a 2^n check to repoman isn't gonna work well.
> > > > > >   
> > > > > 
> > > > > I'm not saying it's the most optimal algorithm of verifying
> > > > > the correctness of the constraints. It's just the one that's
> > > > > quite obvious -- relatively simple and reliable. If someone
> > > > > can come up with something better that covers at least the
> > > > > most common cases, I'm all for it.
> > > > > 
> > > > > That said, this wouldn't be that much of a problem if we can
> > > > > keep the n low. For a start, we can rule out all flags that
> > > > > don't appear in REQUIRED_USE at all. Furthermore, I think we
> > > > > could also ignore the constraints for flags that don't appear
> > > > > there at least 'twice', and so on.
> > > > 
> > > > :)
> > > > 
> > > > You're applying classical techniques to lower the size of a SAT
> > > > instance so that your exponential algorithm does not explode,
> > > > but it's still hard.
> > > > 
> > > > I'm not sure what you want: If you want to detect that there is
> > > > an impossible constraint, well, ebuild writer will notice soon
> > > > enough when testing it. If you want to detect that there is a
> > > > way to have a conflict between useflags, then there will be
> > > > valid cases where this will happen.
> > > > 
> > > > That said, assuming we have REQUIRED_USE in CNF form, its
> > > > negation is in DNF form. Solving SAT on DNF formulas is easy
> > > > (linear I think), and this would give you an assignment of
> > > > useflags triggering an impossible constraint. e.g. 'foo? ( bar
> > > > )' with USE='foo -bar' in make.conf. This could be used to
> > > > trigger a repoman warning but basically every single ebuild
> > > > would trigger those.
> > > 
> > > Not sure if we understand each other.
> > > 
> > > I'd like the constraints to be plain straightforward, to the
> > > point of having only one acceptable solution. No special
> > > Portage-style algorithms that attempt to provide a reasonable
> > > solution to unreasonable input, resulting in horrible solutions
> > > that need 20 more hacks every few months.  
> > 
> > Yes, we definitely agree here. For that, you need to kill the SAT
> > solver and define (spec) what is the straightforward solution, aka a
> > deterministic and straightforward (*) algorithm. Otherwise, you fall
> > into the problems Ciaran explained in an earlier email.
> > 
> > 
> > (*) It's better for the algorithm to be simple enough so that
> > REQUIRED_USE can be written easily for achieving a given behavior.
> > 
> >   
> > > For example:
> > > 
> > >   foo? ( bar )
> > > 
> > > would mean 'if you have USE=foo, then USE=bar is enabled as
> > > well'. Not 'find some random solution which satisfies this'. In
> > > other words, here changing USE=foo into USE=-foo is not an
> > > acceptable solution.  
> > 
> > 
> > What if I specifically set USE=-bar in make.conf ? Do we really
> > want PM to override that without telling me ?  
> 
> Yes. Unless you specifically and explicitly disable that (globally or
> for USE=bar), in which case the PM would just reject to proceed.


Then could you please explain how to get the list of useflags the
solver is allowed to toggle ? Preferably in a PMS-friendly way (aka no
USE=foo emerge). It's not clear to me what this would be and is
mandatory for determinism.

Note that most definitions are acceptable, but there must be one.

> > I believe that, from the ebuild POV, the ternary useflag model is
> > more appropriate: You have a whole bunch of ways to specify
> > useflags with portage (make.conf, package.use, profiles, command
> > line, ...). From the ebuild those are collapsed into 'user input'.
> > You only have IUSE (with its defaults) and that's what the
> > auto-solver should play with: those are the flags that can be
> > toggled.  
> 
> I see your point. However, it's merely a preference problem and we
> really don't want the constraints to become ternary and/or PM try to
> force the reverse solutions. That's an easy way to lose
> predictability.

They're not ternary anymore after processing ebuild: IUSE="foo +bar"
means instantiate foo as -foo if not specified, and bar as +bar.
The way I see it, ternary model is useful in the sense that the 3rd
undefined state 

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Michał Górny]

On śro, 2017-05-31 at 09:32 +0200, Alexis Ballier wrote:
> On Wed, 31 May 2017 08:55:17 +0200
> Michał Górny  wrote:
> 
> > On wto, 2017-05-30 at 20:46 +0200, Alexis Ballier wrote:
> > > On Tue, 30 May 2017 20:11:38 +0200
> > > Michał Górny  wrote:
> > > [...]  
> > > > > > Of course, we could just validate all the possible cases via
> > > > > > repoman, and reject the ebuild if there's at least one
> > > > > > conflict between them. Not sure how to express that properly
> > > > > > in the spec though. Not sure how it would work
> > > > > > practically.
> > > > > 
> > > > > Adding a 2^n check to repoman isn't gonna work well.
> > > > > 
> > > > 
> > > > I'm not saying it's the most optimal algorithm of verifying
> > > > the correctness of the constraints. It's just the one that's quite
> > > > obvious -- relatively simple and reliable. If someone can come up
> > > > with something better that covers at least the most common cases,
> > > > I'm all for it.
> > > > 
> > > > That said, this wouldn't be that much of a problem if we can keep
> > > > the n low. For a start, we can rule out all flags that don't
> > > > appear in REQUIRED_USE at all. Furthermore, I think we could also
> > > > ignore the constraints for flags that don't appear there at least
> > > > 'twice', and so on.  
> > > 
> > > :)
> > > 
> > > You're applying classical techniques to lower the size of a SAT
> > > instance so that your exponential algorithm does not explode, but
> > > it's still hard.
> > > 
> > > I'm not sure what you want: If you want to detect that there is an
> > > impossible constraint, well, ebuild writer will notice soon enough
> > > when testing it. If you want to detect that there is a way to have a
> > > conflict between useflags, then there will be valid cases where this
> > > will happen.
> > > 
> > > That said, assuming we have REQUIRED_USE in CNF form, its negation
> > > is in DNF form. Solving SAT on DNF formulas is easy (linear I
> > > think), and this would give you an assignment of useflags
> > > triggering an impossible constraint. e.g. 'foo? ( bar )' with
> > > USE='foo -bar' in make.conf. This could be used to trigger a
> > > repoman warning but basically every single ebuild would trigger
> > > those.  
> > 
> > Not sure if we understand each other.
> > 
> > I'd like the constraints to be plain straightforward, to the point of
> > having only one acceptable solution. No special Portage-style
> > algorithms that attempt to provide a reasonable solution to
> > unreasonable input, resulting in horrible solutions that need 20 more
> > hacks every few months.
> 
> Yes, we definitely agree here. For that, you need to kill the SAT
> solver and define (spec) what is the straightforward solution, aka a
> deterministic and straightforward (*) algorithm. Otherwise, you fall
> into the problems Ciaran explained in an earlier email.
> 
> 
> (*) It's better for the algorithm to be simple enough so that
> REQUIRED_USE can be written easily for achieving a given behavior.
> 
> 
> > For example:
> > 
> >   foo? ( bar )
> > 
> > would mean 'if you have USE=foo, then USE=bar is enabled as well'. Not
> > 'find some random solution which satisfies this'. In other words, here
> > changing USE=foo into USE=-foo is not an acceptable solution.
> 
> 
> What if I specifically set USE=-bar in make.conf ? Do we really want PM
> to override that without telling me ?

Yes. Unless you specifically and explicitly disable that (globally or
for USE=bar), in which case the PM would just reject to proceed.

> I believe that, from the ebuild POV, the ternary useflag model is more
> appropriate: You have a whole bunch of ways to specify useflags with
> portage (make.conf, package.use, profiles, command line, ...). From the
> ebuild those are collapsed into 'user input'. You only have IUSE (with
> its defaults) and that's what the auto-solver should play with: those
> are the flags that can be toggled.

I see your point. However, it's merely a preference problem and we
really don't want the constraints to become ternary and/or PM try to
force the reverse solutions. That's an easy way to lose predictability.

Besides, I should point out that USE_EXPAND in make.profile
and make.conf are strictly binary. Furthermore, the ternary idea starts
becoming blurry when you have to deal with profiles that you explicitly
want to disable in user configuration.

> > Now, this also means that every constraint that can't be solved in
> > this easy fashion is invalid. We want to detect that, and warn the
> > developer. Some of those could be tricky. Simple example:
> > 
> >   foo? ( baz ) bar? ( !baz )
> > 
> > This one is invalid because USE='foo bar' requires both 'baz' and
> > '!baz' as a solution. Remember that we don't want to do any changes
> > besides what's explicitly written there, no guessing.
> 
> Besides that, what makes it invalid ?

What makes it invalid is that you can't solve it in a predictable way.

> 

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Wed, 31 May 2017 09:54:56 +0200
Alexis Ballier  wrote:

> On Wed, 31 May 2017 08:51:33 +0100
> Ciaran McCreesh  wrote:
> 
> > On Wed, 31 May 2017 09:35:04 +0200
> > Michał Górny  wrote:  
> > > On śro, 2017-05-31 at 08:24 +0100, Ciaran McCreesh wrote:
> > > > On Wed, 31 May 2017 08:55:17 +0200
> > > > Michał Górny  wrote:  
> > > > > For example:
> > > > > 
> > > > >   foo? ( bar )
> > > > > 
> > > > > would mean 'if you have USE=foo, then USE=bar is enabled as
> > > > > well'.  
> > > > 
> > > > What about "if bar cannot be enabled, then turn foo off"?
> > > 
> > > Not expressible. The best you can do is 'if bar is
> > > disabled, ...'
> > 
> > This is the kind of thing that gets very messy when a user wants ssl
> > enabled, and has to enable either openssl or libressl, and they're
> > on a profile where openssl is masked but the ebuild writer prefers
> > that option...
> >   
> 
> ssl? ( ^^ ( openssl libressl ) ) with openssl masked will be reduced
> to 'ssl? ( libressl )' so all good here.
> 

Note: that's also an argument for applying user input before trying to
solve anything. At the very least masks.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Wed, 31 May 2017 08:51:33 +0100
Ciaran McCreesh  wrote:

> On Wed, 31 May 2017 09:35:04 +0200
> Michał Górny  wrote:
> > On śro, 2017-05-31 at 08:24 +0100, Ciaran McCreesh wrote:  
> > > On Wed, 31 May 2017 08:55:17 +0200
> > > Michał Górny  wrote:
> > > > For example:
> > > > 
> > > >   foo? ( bar )
> > > > 
> > > > would mean 'if you have USE=foo, then USE=bar is enabled as
> > > > well'.
> > > 
> > > What about "if bar cannot be enabled, then turn foo off"?  
> > 
> > Not expressible. The best you can do is 'if bar is disabled, ...'  
> 
> This is the kind of thing that gets very messy when a user wants ssl
> enabled, and has to enable either openssl or libressl, and they're on
> a profile where openssl is masked but the ebuild writer prefers that
> option...
> 

ssl? ( ^^ ( openssl libressl ) ) with openssl masked will be reduced to
'ssl? ( libressl )' so all good here.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Ciaran McCreesh]

On Wed, 31 May 2017 09:35:04 +0200
Michał Górny  wrote:
> On śro, 2017-05-31 at 08:24 +0100, Ciaran McCreesh wrote:
> > On Wed, 31 May 2017 08:55:17 +0200
> > Michał Górny  wrote:  
> > > For example:
> > > 
> > >   foo? ( bar )
> > > 
> > > would mean 'if you have USE=foo, then USE=bar is enabled as
> > > well'.  
> > 
> > What about "if bar cannot be enabled, then turn foo off"?
> 
> Not expressible. The best you can do is 'if bar is disabled, ...'

This is the kind of thing that gets very messy when a user wants ssl
enabled, and has to enable either openssl or libressl, and they're on a
profile where openssl is masked but the ebuild writer prefers that
option...

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Michał Górny]

On śro, 2017-05-31 at 08:24 +0100, Ciaran McCreesh wrote:
> On Wed, 31 May 2017 08:55:17 +0200
> Michał Górny  wrote:
> > For example:
> > 
> >   foo? ( bar )
> > 
> > would mean 'if you have USE=foo, then USE=bar is enabled as well'.
> 
> What about "if bar cannot be enabled, then turn foo off"?
> 

Not expressible. The best you can do is 'if bar is disabled, ...'


-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Wed, 31 May 2017 08:24:20 +0100
Ciaran McCreesh  wrote:

> On Wed, 31 May 2017 08:55:17 +0200
> Michał Górny  wrote:
> > For example:
> > 
> >   foo? ( bar )
> > 
> > would mean 'if you have USE=foo, then USE=bar is enabled as well'.  
> 
> What about "if bar cannot be enabled, then turn foo off"?
> 

You ask a constructivist who'll yell at you saying that 'foo -> bar' is
not equivalent to '!bar -> !foo'. You'll have to write the latter as
well if you want that.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Wed, 31 May 2017 08:55:17 +0200
Michał Górny  wrote:

> On wto, 2017-05-30 at 20:46 +0200, Alexis Ballier wrote:
> > On Tue, 30 May 2017 20:11:38 +0200
> > Michał Górny  wrote:
> > [...]  
> > > > > Of course, we could just validate all the possible cases via
> > > > > repoman, and reject the ebuild if there's at least one
> > > > > conflict between them. Not sure how to express that properly
> > > > > in the spec though. Not sure how it would work
> > > > > practically.
> > > > 
> > > > Adding a 2^n check to repoman isn't gonna work well.
> > > > 
> > > 
> > > I'm not saying it's the most optimal algorithm of verifying
> > > the correctness of the constraints. It's just the one that's quite
> > > obvious -- relatively simple and reliable. If someone can come up
> > > with something better that covers at least the most common cases,
> > > I'm all for it.
> > > 
> > > That said, this wouldn't be that much of a problem if we can keep
> > > the n low. For a start, we can rule out all flags that don't
> > > appear in REQUIRED_USE at all. Furthermore, I think we could also
> > > ignore the constraints for flags that don't appear there at least
> > > 'twice', and so on.  
> > 
> > :)
> > 
> > You're applying classical techniques to lower the size of a SAT
> > instance so that your exponential algorithm does not explode, but
> > it's still hard.
> > 
> > I'm not sure what you want: If you want to detect that there is an
> > impossible constraint, well, ebuild writer will notice soon enough
> > when testing it. If you want to detect that there is a way to have a
> > conflict between useflags, then there will be valid cases where this
> > will happen.
> > 
> > That said, assuming we have REQUIRED_USE in CNF form, its negation
> > is in DNF form. Solving SAT on DNF formulas is easy (linear I
> > think), and this would give you an assignment of useflags
> > triggering an impossible constraint. e.g. 'foo? ( bar )' with
> > USE='foo -bar' in make.conf. This could be used to trigger a
> > repoman warning but basically every single ebuild would trigger
> > those.  
> 
> Not sure if we understand each other.
> 
> I'd like the constraints to be plain straightforward, to the point of
> having only one acceptable solution. No special Portage-style
> algorithms that attempt to provide a reasonable solution to
> unreasonable input, resulting in horrible solutions that need 20 more
> hacks every few months.

Yes, we definitely agree here. For that, you need to kill the SAT
solver and define (spec) what is the straightforward solution, aka a
deterministic and straightforward (*) algorithm. Otherwise, you fall
into the problems Ciaran explained in an earlier email.


(*) It's better for the algorithm to be simple enough so that
REQUIRED_USE can be written easily for achieving a given behavior.


> For example:
> 
>   foo? ( bar )
> 
> would mean 'if you have USE=foo, then USE=bar is enabled as well'. Not
> 'find some random solution which satisfies this'. In other words, here
> changing USE=foo into USE=-foo is not an acceptable solution.


What if I specifically set USE=-bar in make.conf ? Do we really want PM
to override that without telling me ?

I believe that, from the ebuild POV, the ternary useflag model is more
appropriate: You have a whole bunch of ways to specify useflags with
portage (make.conf, package.use, profiles, command line, ...). From the
ebuild those are collapsed into 'user input'. You only have IUSE (with
its defaults) and that's what the auto-solver should play with: those
are the flags that can be toggled.


> Now, this also means that every constraint that can't be solved in
> this easy fashion is invalid. We want to detect that, and warn the
> developer. Some of those could be tricky. Simple example:
> 
>   foo? ( baz ) bar? ( !baz )
> 
> This one is invalid because USE='foo bar' requires both 'baz' and
> '!baz' as a solution. Remember that we don't want to do any changes
> besides what's explicitly written there, no guessing.

Besides that, what makes it invalid ? How is it more invalid than '??
( foo bar )' ?

> However, the
> following should be valid:
> 
>   foo? ( baz ) bar? ( !foo !baz )
> 
> Because now we clearly indicate that USE=bar disables USE=foo,
> and therefore makes the first constraint inapplicable. It clearly
> indicates course of action for all combinations:

Ok, I now think you're aiming for giving full power to the solver,
overriding user inputs if necessary. Before going further, I think we
should first agree on what are the useflags such a solver can toggle.
I'm not sure 'USE=foo emerge blah' should disable foo instead of
failing for example.


Alexis.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Ciaran McCreesh]

On Wed, 31 May 2017 08:55:17 +0200
Michał Górny  wrote:
> For example:
> 
>   foo? ( bar )
> 
> would mean 'if you have USE=foo, then USE=bar is enabled as well'.

What about "if bar cannot be enabled, then turn foo off"?

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Michał Górny]

On wto, 2017-05-30 at 20:46 +0200, Alexis Ballier wrote:
> On Tue, 30 May 2017 20:11:38 +0200
> Michał Górny  wrote:
> [...]
> > > > Of course, we could just validate all the possible cases via
> > > > repoman, and reject the ebuild if there's at least one conflict
> > > > between them. Not sure how to express that properly in the spec
> > > > though. Not sure how it would work practically.  
> > > 
> > > Adding a 2^n check to repoman isn't gonna work well.
> > >   
> > 
> > I'm not saying it's the most optimal algorithm of verifying
> > the correctness of the constraints. It's just the one that's quite
> > obvious -- relatively simple and reliable. If someone can come up with
> > something better that covers at least the most common cases, I'm all
> > for it.
> > 
> > That said, this wouldn't be that much of a problem if we can keep the
> > n low. For a start, we can rule out all flags that don't appear
> > in REQUIRED_USE at all. Furthermore, I think we could also ignore
> > the constraints for flags that don't appear there at least 'twice',
> > and so on.
> 
> :)
> 
> You're applying classical techniques to lower the size of a SAT
> instance so that your exponential algorithm does not explode, but it's
> still hard.
> 
> I'm not sure what you want: If you want to detect that there is an
> impossible constraint, well, ebuild writer will notice soon enough when
> testing it. If you want to detect that there is a way to have a
> conflict between useflags, then there will be valid cases where this
> will happen.
> 
> That said, assuming we have REQUIRED_USE in CNF form, its negation is
> in DNF form. Solving SAT on DNF formulas is easy (linear I think), and
> this would give you an assignment of useflags triggering an impossible
> constraint. e.g. 'foo? ( bar )' with USE='foo -bar' in make.conf.
> This could be used to trigger a repoman warning but basically every
> single ebuild would trigger those.

Not sure if we understand each other.

I'd like the constraints to be plain straightforward, to the point of
having only one acceptable solution. No special Portage-style algorithms
that attempt to provide a reasonable solution to unreasonable input,
resulting in horrible solutions that need 20 more hacks every few
months.

For example:

  foo? ( bar )

would mean 'if you have USE=foo, then USE=bar is enabled as well'. Not
'find some random solution which satisfies this'. In other words, here
changing USE=foo into USE=-foo is not an acceptable solution.

Now, this also means that every constraint that can't be solved in this
easy fashion is invalid. We want to detect that, and warn the developer.
Some of those could be tricky. Simple example:

  foo? ( baz ) bar? ( !baz )

This one is invalid because USE='foo bar' requires both 'baz' and '!baz'
as a solution. Remember that we don't want to do any changes besides
what's explicitly written there, no guessing. However, the following
should be valid:

  foo? ( baz ) bar? ( !foo !baz )

Because now we clearly indicate that USE=bar disables USE=foo,
and therefore makes the first constraint inapplicable. It clearly
indicates course of action for all combinations:

  foo bar baz -> foo bar baz
   F   F   F  -> [valid]
   F   F   T  -> [valid]
   F   T   F  -> [valid]
   F   T   T  ->  F   T   F
   T   F   F  ->  T   F   T
   T   F   T  -> [valid]
   T   T   F  ->  F   T   F
   T   T   T  ->  F   T   F

-- 
Best regards,
Michał Górny


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