Upper bounds in PVP WAS: Gearing up (again) for the next release: 2014.2.0.0

Yitzchak Gale gale at sefer.org
Thu Apr 10 20:20:22 UTC 2014


I haven't carefully studied the reason, but the crypto-related packages
cause us more build problems than any other family of packages.
I'm sure we're not the only ones; that's probably why Greg and
others were assuming that they don't comply.

The rampant lack of dependency upper bounds in these
package make them extremely difficult and frustrating to
install.

If you try to install a package depending on tls that is older
than a month or two, it's just a nightmare. One after the next,
crypto packages trick cabal into committing early to a
version that is too new, and then the build fails with some
complex chain of broken dependencies. You fix that one in
cabal.config, and repeat.

Even if the wording about supplying upper bounds in PVP
is "SHOULD", in my opinion that means MUST for inclusion
in HP. Packages in HP are supposed to be stable.

However, I would really like to see tls in HP. Why not just
add the upper bounds?

Thanks,
Yitz

On Thu, Apr 10, 2014 at 2:00 PM, Michael Snoyman <michael at snoyman.com> wrote:
> Starting a separate subject for this response so I don't drive Mark
> absolutely crazy.
>
>
> On Wed, Apr 9, 2014 at 3:19 PM, Vincent Hanquez <tab at snarc.org> wrote:
>>
>> On 2014-04-08 16:29, Gregory Collins wrote:
>>
>>>
>>>
>>>
>>> Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the
>>> Hackage package versioning policy and until this is fixed I think that issue
>>> precludes it from being included in the platform.
>>>
>>
>> First of, you might want to read up on the difference between the
>> definition of policy and rules/law. "obey" doesn't have its place here.
>>
>> Second, the tls/crypto ecosystem is following most of the PvP apart from
>> "3 Dependencies in Cabal".
>>
>> Third, The PvP doesn't actually *enforce* any requirements on
>> dependencies. I can only see CAN, SHOULD, MAY in the section 3.
>> On the other hand, you can find MUST in section "2 Versions numbers", and
>> as far I'm concerned the tls/crypto ecosystem is following each requirements
>> in this section.
>>
>
> Reading that section myself, I have to say I agree with Vincent's
> interpretation. It would seem therefore that the packages under question are
> in fact in compliance with the requirements of the PVP, and therefore
> there's no blocker to including tls in the platform in the future,
> regardless of how you interpret the HP's statement "we follow the Haskell
> Package Versioning Policy".
>
> So if someone wants to object to inclusion of tls, it would have to be on
> technical grounds, rather than simply quoting a document.
>
> Michael
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>


More information about the Libraries mailing list