another possible setup bug: not accepting "provides" name in -P

[Jon Turney]

On 16/08/2025 17:37, Jeremy Drake via Cygwin wrote:
> On Sat, 16 Aug 2025, ASSI via Cygwin wrote:
> 
>> Jeremy Drake via Cygwin writes:
>>> I was trying to clean up my workflows now that llvm 20.1.8-2 is published,
>>> and I came across another possible setup bug.  It seems that the -P option
>>> doesn't accept a package name that is provided rather than being the
>>> actual name of a pacakge.
 >>>>>> llvm20.1-devel is provided by llvm-devel 20.1.8-2, but passing 
that to -P
>>> results in the message: Package 'libllvm20.1-devel' not found.  However,
>>> libclang-devel 20.1.8-2 requires libllvm20.1-devel, and selecting that
>>> version results in "Install libllvm-devel 20.1.8-2 (automatically added)",
>>> so requires does respect provides.
>>
>> Sorry, but it seems you're misusing provides
> 
> Quite possibly, I'm still trying to figure things out ;)
> 
>> (and I'm not clear on
>> whether there should be any dots in the names of provides, but I think
>> it's best avoided).  Provides are meant to guide dependency resolution
>> among a group of packages that belong together, not as an alias for the
>> install package.  It's the installed base package that delivers a
>> provide that ensures that the versions are compatible, so it does not
>> make sense for each and every package to have their own versioned
>> provide, which would imply that one could mix and match between say, lld
>> and llvm-devel versions.

I've read this a dozen times and I still have no idea what this is 
trying to say.

> Regardless, BUILD_REQUIRES is documented to allow provides, and scallywag
> passes BUILD_REQUIRES entries to setup -P, so there's a bug in there
> somewhere.
There's no difference as far as the depsolver is concerned between a 
solution satisfies P where P is implicitly provided by a package P, or 
explicitly provided: by P'.

But there's a very poor separation between UI and data-model in setup, 
so currently the command line options are converted into a UI state of 
package selections, which is then fed into the depsolver.

So yes, I think it's right to call it a bug, but fixing it will requires 
substantial work.

> (A lesser issue is that cygport warns that the provided name is not
> installed when the package that provides it is in fact installed, but this
> is probably a limitation of the installed package database not recording
> what the installed packages provide)

Yes, exactly.

We should be recording all the package's metadata, but installed.db just 
records the name.