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.0.1, 0.1.0.2, 0.1.1, 0.1.2, 0.2, ...some more... ,
>> 0.7.2.2, 0.7.2.3
>> 4) text-foo-0.7.2.3'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