On 31/10/16 08:31 PM, Michał Górny wrote:
> Hello, everyone.
> 
> I would like to work on a major version depedencny specification
> improvements as part of the next EAPI. For this reason, I'd like to
> first gather some research on how developers are using the current
> system, what they find efficient and what they find cumbersome.
> 
> Therefore, I would like to ask the following questions:
> 
> 1. How often do you find '~' useful? Do you think there should be
> additional operators that ignore revision part?

The only time I have used this is when I've needed to synchronize the
version of two inter-dependent packages, while wanting to allow the
revision portion to vary.

I have generally found it a lot more useful to use this in my various
/etc/portage/ files than in ebuilds, though, especially
package.accept_keywords


> 
> 2. How often do you find '=...*' wildcard syntax useful? To what
> purpose do you use it? Do you find its behavior confusing [1]?

I find that this syntax is rather useful and often is necessary, due
to it being difficult to properly define both minimum and maximun
versions otherwise at times -- especially when I want to use the := or
:0= slot operator.  I don't find its behavior confusing once I became
educated on how it actually works; I do recognize that it *is not*
intuitive to the layman.


> 3. Do you sometimes find yourself using '<'/'<=' specs that
> accidentally match _pre/_rc/... versions?

No, but that is likely just because I tend not to deal with
dependencies that have _pre and _rc suffixes.


> 
> 4. What are the common tasks that you find unnecessarily complex /
> lengthy with the current version specifications?

It is cumbersome to deal with limiting slots to a specific subset,
when wanting to leverage slot-operator rebuilds right now --
effectively you need to have two atoms, one with :=, and a second set
||()'d with each of the slots that are compatible.


> 5. Do you find any other parts of the current version dependency
> specifications confusing?

The as yet still impossible means of dealing properly with multiple
packages that should either independently or when switching from one
to another trigger a (sub)slot rebuild is quite vexing at times.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to