A-posteriori .cabal updates don't help (much) with optimistic-upper-bounds

Herbert Valerio Riedel hvr at gnu.org
Mon Dec 3 16:00:15 CET 2012

Malcolm Wallace <malcolm.wallace at me.com> writes:

> On 3 Dec 2012, at 11:35, Herbert Valerio Riedel wrote:

>> 2) there's a package text-foo which depends on 'text >= 0.10' (i.e. with no
>>   upper bound), for which N versions exist on Hackage (all with
>>   the same 'text >= 0.10' constraint):
>>   0.1.0,,, 0.1.1, 0.1.2, 0.2, ...some more... ,
>> 4) text-foo-'s .cabal file is updated server-side to have the
>>   version constraint set to 'text >= 0.10 && text < 0.11'
>> Alas, 4) isn't enough, as it leaves N-1 versions of text-foo with an
>> invalid version constraint
> I don't understand why you suggest that only the most recently
> uploaded version of text-foo would have its cabal file updated on the
> server.  If the scheme is going to work at all, it must update _every_
> version of text-foo that could be affected.

(...in contrast to conservative-bounds, for which the integrity wouldn't
break if one doesn't update *every* version of text-foo with relaxed
bounds -- it would just artificially reduce the reachable space of
compatible package/version combinations)

> Is that an unrealistic expectation?

I don't know... I guess it depends on how much the process of making the
version bounds stricter can be automatized, as otherwise it's a
potentially tedious task that would make it easy to miss something, and
thus not fully re-establish the inter-package version-constraint

Some kind of automatization would also be important in order to keep the
time window as small as possible when Hackage (in its current
implementation) loses temporarily its inter-package integrity due to
uploads of new packages with breaking API changes.


More information about the cabal-devel mailing list