I think we should stop "fixing" other people's packages on Hackage silently

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

I think we should stop "fixing" other people's packages on Hackage silently

Niklas Hambüchen
I'm writing this after having spent many hours of debugging why the
packages "entropy" and "happy" have different compile-time behaviour
when taken from Hackage vs when taken from their upstream git repositories.

After lots of frustration, I finally figured out the problem:

These packages have "Hackage revisions", where their cabal files were
modified from its upstream equivalent:

* https://hackage.haskell.org/package/happy-1.19.5/revisions/
* https://hackage.haskell.org/package/entropy-0.3.7/revisions/

Here, "setup-depends" were added to the cabal file, in order to make the
package build correctly. These changes are on Hackage only, they cannot
be found in the equivalent release of the upstream git repository.

This is *extremely* confusing.

The practice of "fixing up" other people's cabal files behind their back
instead of making those fixes upstream prevents me to use their upstream
git packages to reproduce my issues.

It hides the fact that there is a problem with the upstream package.

In the case of happy, there is not even any upstream fix in the master
branch for the missing setup-depends:

* https://hackage.haskell.org/package/happy-1.19.5/revision/2.cabal vs
* https://github.com/simonmar/happy/blob/2d84ca0/happy.cabal

So in this case, I suspect that the silent "fix" has prevented the
upstream maintainer to even notice that there is a problem with his
package, and so it will be broken again when he uploads the next version.

I understand that the concept of Hackage revisions was introduced in a
commendable effort to improve the package users' experience: Nobody
likes when packages they want to use are broken. And it is clear that
something has to be done when upstream authors don't reply to pull requests.

But I believe this is not the case here.
The upstream maintainers of "happy" and "entropy" are Simon Marlow and
Thomas M. DuBuisson, who are very reliable getting stuff fixed (if they
know about it!) and they apply PRs quickly and their repositories are
well and alive.

I believe we're shooting ourselves in the foot with these fixes: The
time it takes to make an upstream fix and release it as a proper
revision is dwarfed by the time it takes you to figure out bugs when the
code you download from Hackage is not the code that the maintainer put
there, and when package maintainers don't even notice that their
packages are broken because of "silent fixing".

So I would welcome if we could make use of the "Hackage revisions"
feature only in the utmost necessary cases, or even better, never, and
always make properly versioned releases, where a change to any file
implies a bump of the version, so that one can clearly see if one is
dealing with the unmodified upstream code or not.

Greetings,
Niklas
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Benno Fünfstück

At the very least, we should make sure that each revision is accompanied by an upstream PR if it is for the latest release (or any other still supported branch) and the project is hosted on some VCS service that supports PRs.

Regards,
Benno


Niklas Hambüchen <[hidden email]> schrieb am Do., 22. Juni 2017, 18:16:
I'm writing this after having spent many hours of debugging why the
packages "entropy" and "happy" have different compile-time behaviour
when taken from Hackage vs when taken from their upstream git repositories.

After lots of frustration, I finally figured out the problem:

These packages have "Hackage revisions", where their cabal files were
modified from its upstream equivalent:

* https://hackage.haskell.org/package/happy-1.19.5/revisions/
* https://hackage.haskell.org/package/entropy-0.3.7/revisions/

Here, "setup-depends" were added to the cabal file, in order to make the
package build correctly. These changes are on Hackage only, they cannot
be found in the equivalent release of the upstream git repository.

This is *extremely* confusing.

The practice of "fixing up" other people's cabal files behind their back
instead of making those fixes upstream prevents me to use their upstream
git packages to reproduce my issues.

It hides the fact that there is a problem with the upstream package.

In the case of happy, there is not even any upstream fix in the master
branch for the missing setup-depends:

* https://hackage.haskell.org/package/happy-1.19.5/revision/2.cabal vs
* https://github.com/simonmar/happy/blob/2d84ca0/happy.cabal

So in this case, I suspect that the silent "fix" has prevented the
upstream maintainer to even notice that there is a problem with his
package, and so it will be broken again when he uploads the next version.

I understand that the concept of Hackage revisions was introduced in a
commendable effort to improve the package users' experience: Nobody
likes when packages they want to use are broken. And it is clear that
something has to be done when upstream authors don't reply to pull requests.

But I believe this is not the case here.
The upstream maintainers of "happy" and "entropy" are Simon Marlow and
Thomas M. DuBuisson, who are very reliable getting stuff fixed (if they
know about it!) and they apply PRs quickly and their repositories are
well and alive.

I believe we're shooting ourselves in the foot with these fixes: The
time it takes to make an upstream fix and release it as a proper
revision is dwarfed by the time it takes you to figure out bugs when the
code you download from Hackage is not the code that the maintainer put
there, and when package maintainers don't even notice that their
packages are broken because of "silent fixing".

So I would welcome if we could make use of the "Hackage revisions"
feature only in the utmost necessary cases, or even better, never, and
always make properly versioned releases, where a change to any file
implies a bump of the version, so that one can clearly see if one is
dealing with the unmodified upstream code or not.

Greetings,
Niklas
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Herbert Valerio Riedel-3
Hi,

On 2017-06-22 at 18:59:31 +0200, Benno Fünfstück wrote:
> At the very least, we should make sure that each revision is accompanied by
> an upstream PR if it is for the latest release (or any other still
> supported branch) and the project is hosted on some VCS service that
> supports PRs.

Yes! It's obviously good practice to inform maintainers about problems
with their meta-data which require changes!

And in fact, here's the ticket where it was discussed for entropy

 https://github.com/TomMD/entropy/issues/32 

...and as for happy (since I'm in frequent communication with Simon) I just
left a note to pursue this at our next discussion

 https://github.com/simonmar/happy/issues/61#issuecomment-309669819


Cheers,
  Herbert
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

MarLinn
In reply to this post by Benno Fünfstück

> At the very least, we should make sure that each revision is
> accompanied by an upstream PR if it is for the latest release (or any
> other still supported branch) and the project is hosted on some VCS
> service that supports PRs.
>

Why "and" instead of "if"?

A VCS is certainly a good idea. But a (public) VCS service? Why? Keep in
mind that Github and its clones are only one of many options for
software management. So why force maintainers to keep up with yet
another service if they don't really want or need it? That only reduces
the number of willing contributers and forces people into systems that
they won't really use, so it wouldn't even solve the problem.

I get the sentiment, but if email is good enough as a last-stage
PR-queue for the Linux Kernel, we should allow package maintainers the
same. If that makes it harder for them to integrate changes, that's
their problem. (But one could always use a format that's easy to parse.)

Bonus: automatic "PR's" via email should be dead-easy to implement and
maintain compared to all alternatives.

Cheers,
MarLinn

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Joachim Durchholz
In reply to this post by Niklas Hambüchen
Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen:
> So I would welcome if we could make use of the "Hackage revisions"
> feature only in the utmost necessary cases, or even better, never, and
> always make properly versioned releases, where a change to any file
> implies a bump of the version, so that one can clearly see if one is
> dealing with the unmodified upstream code or not.

I'd like to recommend the approach taken by Linux distros: If the
package is modified vs. the original code, use a version numbering
scheme that clearly indicates both the original version and a "packaging
revision number".
https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
updates should really be three revisions:
   happy-1.19.5 (original version uploaded by Simon)
   happy-1.19.5-hackage-1 (2015 update)
   happy-1.19.5-hackage-2 (2017 update)

The assumption here is that Simon will bump the version to happy-1.19.6
before uploading the fixed package.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Benno Fünfstück
In reply to this post by MarLinn
That should be read as "if (... And ...)" So I'm not recommending to force anyone to use a public VCS, I only wanted to express that revisions should be fine if there is no way to contact upstream devs (no public VCS was just an example here)

MarLinn <[hidden email]> schrieb am Do., 22. Juni 2017, 20:20:

> At the very least, we should make sure that each revision is
> accompanied by an upstream PR if it is for the latest release (or any
> other still supported branch) and the project is hosted on some VCS
> service that supports PRs.
>

Why "and" instead of "if"?

A VCS is certainly a good idea. But a (public) VCS service? Why? Keep in
mind that Github and its clones are only one of many options for
software management. So why force maintainers to keep up with yet
another service if they don't really want or need it? That only reduces
the number of willing contributers and forces people into systems that
they won't really use, so it wouldn't even solve the problem.

I get the sentiment, but if email is good enough as a last-stage
PR-queue for the Linux Kernel, we should allow package maintainers the
same. If that makes it harder for them to integrate changes, that's
their problem. (But one could always use a format that's easy to parse.)

Bonus: automatic "PR's" via email should be dead-easy to implement and
maintain compared to all alternatives.

Cheers,
MarLinn

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Benno Fünfstück
In reply to this post by Joachim Durchholz
There is an X-Revision field in the cabal file, perhaps cabal-install should display it more prominently ( is it even displayed at all right now? )



Joachim Durchholz <[hidden email]> schrieb am Do., 22. Juni 2017, 21:08:
Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen:
> So I would welcome if we could make use of the "Hackage revisions"
> feature only in the utmost necessary cases, or even better, never, and
> always make properly versioned releases, where a change to any file
> implies a bump of the version, so that one can clearly see if one is
> dealing with the unmodified upstream code or not.

I'd like to recommend the approach taken by Linux distros: If the
package is modified vs. the original code, use a version numbering
scheme that clearly indicates both the original version and a "packaging
revision number".
https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
updates should really be three revisions:
   happy-1.19.5 (original version uploaded by Simon)
   happy-1.19.5-hackage-1 (2015 update)
   happy-1.19.5-hackage-2 (2017 update)

The assumption here is that Simon will bump the version to happy-1.19.6
before uploading the fixed package.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Joachim Durchholz
People expect the version number to uniquely identify the version of the
package, so I think the Hackage revision should be included in the
version number.
If that means ugly version numbers: So be it, it's an incentive to tell
upstream to update their code :-)

Am 22.06.2017 um 21:25 schrieb Benno Fünfstück:

> There is an X-Revision field in the cabal file, perhaps cabal-install
> should display it more prominently ( is it even displayed at all right
> now? )
>
> https://hackage.haskell.org/package/happy-1.19.5/happy.cabal
>
>
> Joachim Durchholz <[hidden email] <mailto:[hidden email]>> schrieb
> am Do., 22. Juni 2017, 21:08:
>
>     Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen:
>      > So I would welcome if we could make use of the "Hackage revisions"
>      > feature only in the utmost necessary cases, or even better,
>     never, and
>      > always make properly versioned releases, where a change to any file
>      > implies a bump of the version, so that one can clearly see if one is
>      > dealing with the unmodified upstream code or not.
>
>     I'd like to recommend the approach taken by Linux distros: If the
>     package is modified vs. the original code, use a version numbering
>     scheme that clearly indicates both the original version and a "packaging
>     revision number".
>     https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
>     updates should really be three revisions:
>         happy-1.19.5 (original version uploaded by Simon)
>         happy-1.19.5-hackage-1 (2015 update)
>         happy-1.19.5-hackage-2 (2017 update)
>
>     The assumption here is that Simon will bump the version to happy-1.19.6
>     before uploading the fixed package.
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     Only members subscribed via the mailman list are allowed to post.
>

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Bardur Arantsson-2
In reply to this post by Joachim Durchholz
On 2017-06-22 21:07, Joachim Durchholz wrote:

> Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen:
>> So I would welcome if we could make use of the "Hackage revisions"
>> feature only in the utmost necessary cases, or even better, never, and
>> always make properly versioned releases, where a change to any file
>> implies a bump of the version, so that one can clearly see if one is
>> dealing with the unmodified upstream code or not.
>
> I'd like to recommend the approach taken by Linux distros: If the
> package is modified vs. the original code, use a version numbering
> scheme that clearly indicates both the original version and a "packaging
> revision number".
> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
> updates should really be three revisions:
>   happy-1.19.5 (original version uploaded by Simon)
>   happy-1.19.5-hackage-1 (2015 update)
>   happy-1.19.5-hackage-2 (2017 update)
>
> The assumption here is that Simon will bump the version to happy-1.19.6
> before uploading the fixed package.

+1000

Regards,

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Ivan Lazar Miljenovic
In reply to this post by Joachim Durchholz
On 23 June 2017 at 05:07, Joachim Durchholz <[hidden email]> wrote:

> Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen:
>>
>> So I would welcome if we could make use of the "Hackage revisions"
>> feature only in the utmost necessary cases, or even better, never, and
>> always make properly versioned releases, where a change to any file
>> implies a bump of the version, so that one can clearly see if one is
>> dealing with the unmodified upstream code or not.
>
>
> I'd like to recommend the approach taken by Linux distros: If the package is
> modified vs. the original code, use a version numbering scheme that clearly
> indicates both the original version and a "packaging revision number".
> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
> updates should really be three revisions:
>   happy-1.19.5 (original version uploaded by Simon)
>   happy-1.19.5-hackage-1 (2015 update)
>   happy-1.19.5-hackage-2 (2017 update)

The problem being that Data.Version has deprecated the tags field, so
we can't have that format.

What about just appending one extra version field (assuming PVP, so
bump/add field n >= 5) ?

>
> The assumption here is that Simon will bump the version to happy-1.19.6
> before uploading the fixed package.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Joachim Durchholz
Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic:

> On 23 June 2017 at 05:07, Joachim Durchholz <[hidden email]> wrote:
>> I'd like to recommend the approach taken by Linux distros: If the package is
>> modified vs. the original code, use a version numbering scheme that clearly
>> indicates both the original version and a "packaging revision number".
>> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
>> updates should really be three revisions:
>>    happy-1.19.5 (original version uploaded by Simon)
>>    happy-1.19.5-hackage-1 (2015 update)
>>    happy-1.19.5-hackage-2 (2017 update)
>
> The problem being that Data.Version has deprecated the tags field, so
> we can't have that format.

I gather that the tags are about to be dropped because they don't
participate in ordering, violating either Eq or Ord requirements.
Tags could be included in ordering to fix that; however, this would get
the wrong order when comparing these two:
   1.19.5-hackage-9  -> ([1, 19, 5), ["hackage", "9"])
   1.19.5-hackage-10 -> ([1, 19, 5), ["hackage", "10"])

The standard version comparison semantics is:
* Split the string at digit/nondigit boundaries into subsequences
* Digit subsequences are always greater than nondigit ones (this deals
with projects that release 1.19 initially and then continue with 1.19.1,
and also correctly sorts 1.19-hackage-0 before 1.19.1-hackage-0)
* If both subsequences are digits, use numeric comparison, otherwise use
string comparison.

This turns
   1.19.5-hackage-2
into
   1
   .
   19
   .
   5
   -hackage-
   2

This looks weird, but not so much if you consider that in practice, you
never write down or see individual components but prefixes:
   1
   1.19
   1.19.5
   1.19.5-hackage
   1.19.5-hackage-2

Version comparison specs usually omit the following situations because
you never care about them in practice:
- how to compare "007" and "7" (there are arguments for all three of <,
=, and > so you can expect inconsistencies between ecosystems here)
- whether to handle punctuation differently from letters or not (usually
it's "use the simplest implementation", i.e. handle them as if they were
letters)
- how to deal with Unicode characters in nondigits subsequences (again,
"simplest implementation", i.e. just use ByteString semantics)

Disclaimer: The above is what I have been observing the version number
comparisons converge to, in the the Linux package and the Java library
ecosystems. Reports about ecosystems with different version "number"
comparison conventions would be interesting to me.

> What about just appending one extra version field (assuming PVP, so
> bump/add field n >= 5) ?

I don't know what PVP and n are in this context.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Benno Fünfstück

Why would it need to be included in the version number? Note that, compared to version numbers, the revision number does not take part in dependency resolution (cabal always picks the latest revision AFAIK)

I suggest that cabal should print something like:

Building foo-1.2.3 (revision 2)

If it uses a revision. This does not require the version number to change, it only changes the output of cabal so it should be uncontroversial and simple to implement.

This would increase visibility in the case that a revision is used. There may be more places where this output makes sense, not just when printing the Building... Message

Regards,

Benno


Joachim Durchholz <[hidden email]> schrieb am Fr., 23. Juni 2017, 10:05:
Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic:
> On 23 June 2017 at 05:07, Joachim Durchholz <[hidden email]> wrote:
>> I'd like to recommend the approach taken by Linux distros: If the package is
>> modified vs. the original code, use a version numbering scheme that clearly
>> indicates both the original version and a "packaging revision number".
>> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!)
>> updates should really be three revisions:
>>    happy-1.19.5 (original version uploaded by Simon)
>>    happy-1.19.5-hackage-1 (2015 update)
>>    happy-1.19.5-hackage-2 (2017 update)
>
> The problem being that Data.Version has deprecated the tags field, so
> we can't have that format.

I gather that the tags are about to be dropped because they don't
participate in ordering, violating either Eq or Ord requirements.
Tags could be included in ordering to fix that; however, this would get
the wrong order when comparing these two:
   1.19.5-hackage-9  -> ([1, 19, 5), ["hackage", "9"])
   1.19.5-hackage-10 -> ([1, 19, 5), ["hackage", "10"])

The standard version comparison semantics is:
* Split the string at digit/nondigit boundaries into subsequences
* Digit subsequences are always greater than nondigit ones (this deals
with projects that release 1.19 initially and then continue with 1.19.1,
and also correctly sorts 1.19-hackage-0 before 1.19.1-hackage-0)
* If both subsequences are digits, use numeric comparison, otherwise use
string comparison.

This turns
   1.19.5-hackage-2
into
   1
   .
   19
   .
   5
   -hackage-
   2

This looks weird, but not so much if you consider that in practice, you
never write down or see individual components but prefixes:
   1
   1.19
   1.19.5
   1.19.5-hackage
   1.19.5-hackage-2

Version comparison specs usually omit the following situations because
you never care about them in practice:
- how to compare "007" and "7" (there are arguments for all three of <,
=, and > so you can expect inconsistencies between ecosystems here)
- whether to handle punctuation differently from letters or not (usually
it's "use the simplest implementation", i.e. handle them as if they were
letters)
- how to deal with Unicode characters in nondigits subsequences (again,
"simplest implementation", i.e. just use ByteString semantics)

Disclaimer: The above is what I have been observing the version number
comparisons converge to, in the the Linux package and the Java library
ecosystems. Reports about ecosystems with different version "number"
comparison conventions would be interesting to me.

> What about just appending one extra version field (assuming PVP, so
> bump/add field n >= 5) ?

I don't know what PVP and n are in this context.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Ivan Lazar Miljenovic
In reply to this post by Joachim Durchholz
On 23 June 2017 at 18:03, Joachim Durchholz <[hidden email]> wrote:
> Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic:
>> What about just appending one extra version field (assuming PVP, so
>> bump/add field n >= 5) ?
>
>
> I don't know what PVP and n are in this context.

The Package Versioning Policy and "field n" (or "nth component of the version").

--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Joachim Durchholz
In reply to this post by Benno Fünfstück
Am 23.06.2017 um 10:27 schrieb Benno Fünfstück:
> Why would it need to be included in the version number? Note that,
> compared to version numbers, the revision number does not take part in
> dependency resolution (cabal always picks the latest revision AFAIK)

Dependencies specify minimum and/or maximum revisions, so revision
ordering is really important.

> I suggest that cabal should print something like:
>
> Building foo-1.2.3 (revision 2)
>
> If it uses a revision. This does not require the version number to
> change, it only changes the output of cabal so it should be
> uncontroversial and simple to implement.

I'm feeling uneasy about that, for various reasons.
1) "Revision" is a somewhat vague terminology here. It's unclear what
kind of revision, and how that's different from a version. From what I
gather, it's essentially just a sub-version of 1.2.3 created by the
Hackage people instead of original upstream.
2) Having a version and a revision works fine if there are two parties
involved (in this case: upstream and Hackage guys). The approach doesn't
scale to more parties, which is rare but does happen.
3) Also, "revision" might not just cut it. E.g. Maven (Java's moral
equivalent of Hackage) offers two kinds of modules, productive (never
ever change) and snapshot (may change at the drop of the hat), and
snapshot versions/revisions are simply marked by a SNAPSHOT part in the
version number. If a repository offers more module categories, it will
want to differentiate between them; since the set of categories may grow
over time, and different repositories may offer different categories,
you want that to be extensible.

Essentially, it boils down to "there should a single identifier for a
specific build of a module, let's call that the module version; and
different repositories may have different needs so a mere integer list
doesn't but it".

 From another perspective, allowing strings in versions subsumes tags,
but in a semantically clean way.

Just my 2 cents.

> This would increase visibility in the case that a revision is used.
> There may be more places where this output makes sense, not just when
> printing the Building... Message
>
> Regards,
>
> Benno
>
>
> Joachim Durchholz <[hidden email] <mailto:[hidden email]>> schrieb
> am Fr., 23. Juni 2017, 10:05:
>
>     Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic:
>      > On 23 June 2017 at 05:07, Joachim Durchholz <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >> I'd like to recommend the approach taken by Linux distros: If
>     the package is
>      >> modified vs. the original code, use a version numbering scheme
>     that clearly
>      >> indicates both the original version and a "packaging revision
>     number".
>      >> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with
>     two(!)
>      >> updates should really be three revisions:
>      >>    happy-1.19.5 (original version uploaded by Simon)
>      >>    happy-1.19.5-hackage-1 (2015 update)
>      >>    happy-1.19.5-hackage-2 (2017 update)
>      >
>      > The problem being that Data.Version has deprecated the tags field, so
>      > we can't have that format.
>
>     I gather that the tags are about to be dropped because they don't
>     participate in ordering, violating either Eq or Ord requirements.
>     Tags could be included in ordering to fix that; however, this would get
>     the wrong order when comparing these two:
>         1.19.5-hackage-9  -> ([1, 19, 5), ["hackage", "9"])
>         1.19.5-hackage-10 -> ([1, 19, 5), ["hackage", "10"])
>
>     The standard version comparison semantics is:
>     * Split the string at digit/nondigit boundaries into subsequences
>     * Digit subsequences are always greater than nondigit ones (this deals
>     with projects that release 1.19 initially and then continue with 1.19.1,
>     and also correctly sorts 1.19-hackage-0 before 1.19.1-hackage-0)
>     * If both subsequences are digits, use numeric comparison, otherwise use
>     string comparison.
>
>     This turns
>         1.19.5-hackage-2
>     into
>         1
>         .
>         19
>         .
>         5
>         -hackage-
>         2
>
>     This looks weird, but not so much if you consider that in practice, you
>     never write down or see individual components but prefixes:
>         1
>         1.19
>         1.19.5
>         1.19.5-hackage
>         1.19.5-hackage-2
>
>     Version comparison specs usually omit the following situations because
>     you never care about them in practice:
>     - how to compare "007" and "7" (there are arguments for all three of <,
>     =, and > so you can expect inconsistencies between ecosystems here)
>     - whether to handle punctuation differently from letters or not (usually
>     it's "use the simplest implementation", i.e. handle them as if they were
>     letters)
>     - how to deal with Unicode characters in nondigits subsequences (again,
>     "simplest implementation", i.e. just use ByteString semantics)
>
>     Disclaimer: The above is what I have been observing the version number
>     comparisons converge to, in the the Linux package and the Java library
>     ecosystems. Reports about ecosystems with different version "number"
>     comparison conventions would be interesting to me.
>
>      > What about just appending one extra version field (assuming PVP, so
>      > bump/add field n >= 5) ?
>
>     I don't know what PVP and n are in this context.
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     Only members subscribed via the mailman list are allowed to post.
>

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Andrew Cowie-3
In reply to this post by Ivan Lazar Miljenovic
On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic <[hidden email]> wrote:
The problem being that Data.Version has deprecated the tags field,

So, undeprecate it.

AfC


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Brandon Allbery
On Tue, Jun 27, 2017 at 1:10 AM, Andrew Cowie <[hidden email]> wrote:
On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic <[hidden email]> wrote:
The problem being that Data.Version has deprecated the tags field,

So, undeprecate it.

Only if you can define a sensible behavior for it; the main reason for deprecating it, as I understand it, is its semantics were never defined and it could therefore never be actually used for anything.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: I think we should stop "fixing" other people's packages on Hackage silently

Joachim Durchholz
In reply to this post by Andrew Cowie-3
Am 27.06.2017 um 07:10 schrieb Andrew Cowie:
> On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     The problem being that Data.Version has deprecated the tags field,
>
>
> So, undeprecate it.

The patch that deprecates it mentions problems with Eq and Ord.
I suspect the implementation is inconsistent with the axioms.

Also, a list of tags independent of version numbers isn't exactly what
would be needed to differentiate between two versions on Hackage, you
actually need an "upstream" and a "Hackage" version number, plus maybe
more version numbers if a piece of code goes through more stations.

I.e. that wouldn't solve the problem, it needs to be replaced with
something better.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.