|Summary:||[Future EAPI] Allow alternative version restriction syntax: <pkg> [<op> <version>]|
|Product:||Gentoo Hosted Projects||Reporter:||Michał Górny <mgorny>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Michał Górny 2016-10-31 14:20:47 UTC
== Problem == Currently, the package dependencies have the form: [<op>] <cat> "/" <pkg> ["-" <ver> ["*"]] [":" <slot>] ["[" <usedep> "]"] ^^^^^^ ^^^^^^^^^^^^^^^^^ I see two major problems with how version dependencies are expressed. Firstly, the operator and the version specification are disjoint. Secondly, the version specification is separated from package name by a single hyphen which is also a valid package name character. This has the following implications: 1. Expressing the syntax somewhat strictly is hard if not impossible e.g. using regular expressions. 2. Splitting the package name from version is a PITA, especially when you have to deal with mixed non-versioned and versioned input. 3. We have to force arbitrary restrictions on package names to avoid confusing parts of name with versions. 4. Splitting closely related information makes the syntax less readable, and harder to edit (you have to alter both text at the beginning and in the middle of the dependency specification). 5. The syntax is somewhat limiting to a single version specification, which e.g. already caused problems when considering version ranges (bug #4315). == Solution == As a solution, I would like a new EAPI to allow (and encourage) the following syntax: <cat> "/" <pkg> [":" <slot>] [<op> <ver> ["*"]] ["[" <usedep> "]"] ^^^^^^^^^^^^^^^^^^ I think the advantages are clearly seen. The version comparison part comprises a single segment. Therefore: 1. Expressing the syntax using regular expressions becomes easier. It still can't be very strict but at least we can detect simple mistakes like using operator with no version (not that people are likely to do them anymore). 2. The version is clearly separated from package name, and can be split using simple character ranges. 3. We might be able to lift the stupid restrictions at some point in the future. 4. Reading and altering the dependency specifications becomes easier. You don't have to jump around it. You less often accidentally leave the operator after removing version, or the other way around. 5. We can fit version ranges in this syntax easily. 6. Exherbo does something like that, so it must be correct™ . I've also reordered slot before version since this way seems more hierarchically correct (package -> slot -> version -> USE flags). :https://exherbo.org/docs/eapi/exheres-for-smarties.html#package_dependencies == Backwards compatibility == The usual deal. We allow the new syntax in one EAPI, and declare that we will drop support for the old one in some future EAPI (i.e. never). Until then, people can mix both. When people update packages, they slowly move to the new syntax. Eclasses can either move to the new syntax when they drop support for old EAPIs, or just use both conditionally. The package managers can support either syntax independently of ebuilds. However, I think using the new one by default will improve readability and input-friendliness.
Comment 1 Michał Górny 2016-10-31 17:29:29 UTC
Side note: I would also like to start killing uses of the terrible 'CPV' in Portage output with 'package==version' (or a single '=' if that is found preferred).
Comment 2 Ciaran McCreesh 2016-10-31 18:30:52 UTC
The annoying bit is dealing with user configs, etc, in the old format. Exherbo sticks the version requirements inside a  to simplify that, and to make parsing longer operations like version ranges easier.