Proposal: Ignore sub-minor version components in package id
Hi, I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them. By the package versioning policy, if the API stays the same, these version numbers stay identical. And if the change does not affect the ABI, the hash stays the same. This would allow upgrades of the package without having to re-build everything depending on it. And if the maintainer does not fully follow the PVP, then it is not a big deal either; the hash will change and Cabal will enforce rebuilds. One could argue that the version can be removed entirely from the package id, but it helps the human reader when looking at the "depends" field of a package. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
On Mon, 2011-10-03 at 13:18 +0200, Joachim Breitner wrote:
I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them.
...would this affect the ability to declare version constraints that use more than the first 3 components? E.g. would the following Cabal statement Build-depends: aeson >=0.3.2.12 && <0.4 still work (and force at least version 0.3.2.12 of aeson to be used)? -- hvr
Hi, Am Montag, den 03.10.2011, 13:27 +0200 schrieb Herbert Valerio Riedel:
On Mon, 2011-10-03 at 13:18 +0200, Joachim Breitner wrote:
I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them.
...would this affect the ability to declare version constraints that use more than the first 3 components? E.g. would the following Cabal statement
Build-depends: aeson >=0.3.2.12 && <0.4
still work (and force at least version 0.3.2.12 of aeson to be used)?
yes, all other version-related machinery (dependencies in Cabal packages, hackage stuff etc) still work. I am only talking about the packages as registered with ghc-pkg, not the packages as specified by .cabal. In distribution-lingo, the former are binary packages and the latter are source packages. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
On 3 October 2011 22:30, Joachim Breitner
Hi,
Am Montag, den 03.10.2011, 13:27 +0200 schrieb Herbert Valerio Riedel:
On Mon, 2011-10-03 at 13:18 +0200, Joachim Breitner wrote:
I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them.
...would this affect the ability to declare version constraints that use more than the first 3 components? E.g. would the following Cabal statement
Build-depends: aeson >=0.3.2.12 && <0.4
still work (and force at least version 0.3.2.12 of aeson to be used)?
yes, all other version-related machinery (dependencies in Cabal packages, hackage stuff etc) still work.
I am only talking about the packages as registered with ghc-pkg, not the packages as specified by .cabal. In distribution-lingo, the former are binary packages and the latter are source packages.
Would this not make it harder to determine which exact version of a package you have installed? I believe cabal-install uses ghc-pkg to know which versions are installed, so how would it know whether you have the latest bug-fix release installed? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
Hi, Am Montag, den 03.10.2011, 22:52 +1100 schrieb Ivan Lazar Miljenovic:
I am only talking about the packages as registered with ghc-pkg, not the packages as specified by .cabal. In distribution-lingo, the former are binary packages and the latter are source packages.
Would this not make it harder to determine which exact version of a package you have installed? I believe cabal-install uses ghc-pkg to know which versions are installed, so how would it know whether you have the latest bug-fix release installed?
no, that would also not be the case. Have a look at "ghc-pkg describe network". You see that it keeps track of the version in a field of its own. I am only talking about the id that appears in the "id" and "depends" fields. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
On 4 October 2011 08:32, Joachim Breitner
Hi,
Am Montag, den 03.10.2011, 22:52 +1100 schrieb Ivan Lazar Miljenovic:
I am only talking about the packages as registered with ghc-pkg, not the packages as specified by .cabal. In distribution-lingo, the former are binary packages and the latter are source packages.
Would this not make it harder to determine which exact version of a package you have installed? I believe cabal-install uses ghc-pkg to know which versions are installed, so how would it know whether you have the latest bug-fix release installed?
no, that would also not be the case.
Have a look at "ghc-pkg describe network". You see that it keeps track of the version in a field of its own. I am only talking about the id that appears in the "id" and "depends" fields.
In that case, if the ABI doesn't change, +1 for packages with 4 version components (I seem to recall some bindings package that had a version ID consisting of the upstream C library version, and _then_ a 4 digit package version). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
Would it be simpler to not use the version at all for calculating installed
package ABI identity?
You could still show it, though.
On Oct 3, 2011 6:19 AM, "Joachim Breitner"
Hi,
I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them.
By the package versioning policy, if the API stays the same, these version numbers stay identical. And if the change does not affect the ABI, the hash stays the same. This would allow upgrades of the package without having to re-build everything depending on it.
And if the maintainer does not fully follow the PVP, then it is not a big deal either; the hash will change and Cabal will enforce rebuilds.
One could argue that the version can be removed entirely from the package id, but it helps the human reader when looking at the "depends" field of a package.
Greetings, Joachim
-- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Mon, 2011-10-03 at 13:18 +0200, Joachim Breitner wrote:
Hi,
I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them.
So I agree with your aims but I suggest a different approach. Also, we're conflating issues here: The "id" field (or the InstalledPackageId in Cabal parlance) is used to uniquely identify each package. This is not the same thing as an ABI. Note that currently, confusingly, the package id that Cabal creates (for ghc) is made up of the package name, version and abi hash. This makes people think it is an abi identifier when it is not. We need (in future) to be able to distinguish different packages that share the same ABI. So what needs to happen is that we include the ABI as a separate field in the package db. That abi need not contain the version number at all, it can be just some abi hash. Then whether the dependencies should then use an installed package id or a package abi is an interesting question. I think the right thing is to use installed package ids. Just because it would be possible to update a dependency to use the latest-ABI compatible version doesn't mean that it should be immediate and automatic. Indeed it would prevent us from having a persistent package database, as adding new packages would change the meaning of existing packages. Switching to a later ABI-compatible version of a dependency should be a deliberate act. Hence we should use installed package ids for dependencies. Duncan
On 8 November 2011 23:25, Duncan Coutts
Then whether the dependencies should then use an installed package id or a package abi is an interesting question. I think the right thing is to use installed package ids. Just because it would be possible to update a dependency to use the latest-ABI compatible version doesn't mean that it should be immediate and automatic. Indeed it would prevent us from having a persistent package database, as adding new packages would change the meaning of existing packages. Switching to a later ABI-compatible version of a dependency should be a deliberate act. Hence we should use installed package ids for dependencies.
Are you referring to Cabal or cabal-install for this? (I'm assuming the latter) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
Hi Duncan, Am Dienstag, den 08.11.2011, 12:25 +0000 schrieb Duncan Coutts:
On Mon, 2011-10-03 at 13:18 +0200, Joachim Breitner wrote:
I’d like to propose that the package (shown by "ghc-pkg field <pkg> id" and used by "ghc-pkg field <pkg> depends") should only consist of the first three components of the package version, not all of them.
So I agree with your aims but I suggest a different approach.
Also, we're conflating issues here:
The "id" field (or the InstalledPackageId in Cabal parlance) is used to uniquely identify each package.
This is not the same thing as an ABI.
Note that currently, confusingly, the package id that Cabal creates (for ghc) is made up of the package name, version and abi hash. This makes people think it is an abi identifier when it is not.
We need (in future) to be able to distinguish different packages that share the same ABI. So what needs to happen is that we include the ABI as a separate field in the package db. That abi need not contain the version number at all, it can be just some abi hash.
Then whether the dependencies should then use an installed package id or a package abi is an interesting question. I think the right thing is to use installed package ids. Just because it would be possible to update a dependency to use the latest-ABI compatible version doesn't mean that it should be immediate and automatic. Indeed it would prevent us from having a persistent package database, as adding new packages would change the meaning of existing packages. Switching to a later ABI-compatible version of a dependency should be a deliberate act. Hence we should use installed package ids for dependencies.
thanks for your feedback. I’m not sure how your approach helps with my aim, which is: I want to be able to upgrade dependencies without having to recompile depending packages, unless the ABI changes. If the depends field of an installed package refers to the package id, then either I have to rebuild the package; or a new operation “use newer package with the same ABI” needs to be introduced, which would change the depends field of an installed package to a new id, under the provision that the ABI is the same. Is that what you are hinting at? Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
On Tue, 2011-11-08 at 15:39 +0100, Joachim Breitner wrote:
We need (in future) to be able to distinguish different packages that share the same ABI. So what needs to happen is that we include the ABI as a separate field in the package db. That abi need not contain the version number at all, it can be just some abi hash.
Then whether the dependencies should then use an installed package id or a package abi is an interesting question. I think the right thing is to use installed package ids. Just because it would be possible to update a dependency to use the latest-ABI compatible version doesn't mean that it should be immediate and automatic. Indeed it would prevent us from having a persistent package database, as adding new packages would change the meaning of existing packages. Switching to a later ABI-compatible version of a dependency should be a deliberate act. Hence we should use installed package ids for dependencies.
thanks for your feedback. I’m not sure how your approach helps with my aim, which is: I want to be able to upgrade dependencies without having to recompile depending packages, unless the ABI changes.
If the depends field of an installed package refers to the package id, then either I have to rebuild the package; or a new operation “use newer package with the same ABI” needs to be introduced, which would change the depends field of an installed package to a new id, under the provision that the ABI is the same. Is that what you are hinting at?
Yes exactly. The latter, an explicit "switch dependency" operation. Of course that operation might be performed automatically by some higher level tool like cabal, according to some policy. But at the level of mechanism (ie ghc-pkg db) it should be an explicit thing. Of course in the bright future world of persistent package management that'd really involve making a new installed package instance with the new dependency but sharing the same installed files... :-) Duncan
participants (5)
-
Antoine Latter -
Duncan Coutts -
Herbert Valerio Riedel -
Ivan Lazar Miljenovic -
Joachim Breitner