[indiana-discuss] [pkg-discuss] pkg won't install older versions of packages

[Shawn Walker]

Bart Smaalders wrote:
> Shawn Walker wrote:
>> Danek Duvall wrote:
>>> On Wed, Apr 22, 2009 at 04:00:14PM -0500, Shawn Walker wrote:
>>>
>>>> If I may ask, what do you feel is the issue with pkg:/ ?
>>>
>>> It doesn't strike me as having anything to do with the version, and so
>>> using it to anchor the version doesn't make much sense.  Also, more
>>> concretely, what if I want to add a package from a specific authority,
>>> but want the version to float in a limited range?
>>
>> My problem with using a flag was that it then makes exact matching 
>> dependent upon the command instead of the syntax.  I also assumed that 
>> when you specified an authority, you didn't want to float in a limited 
>> range.
>>
>> Does anyone have better suggestions for a syntax alternative?
>>
>> It seems far easier to me to assume exact match, and then only float 
>> versions if told to...
>>
> 
> I'd just as soon do the following:
> 
> 1) if there are no constraints on the image, do what the user specifies, 
> but take the latest package that matches the specification:
> 
>   foo at 1.0  would match foo at 1.0.1, for example/
> 
> To permit the installation of foo at 1.0 when foo at 1.0.1 exists, allow
> the specification of extra .0s as needed as in:
> 
>   foo at 1.0.0, which would not match foo at 1.0.1
> 
> 2) If there are constraints on the image such that the user's spec.
> cannot be met as in 1), fail the install.

The last time we had this discussion was when I wrote the 
MatchingVersion class.  The conclusion then was that 3.2 should only 
match 3.2, while 3.2.* could match 3.2, 3.2.1, 3.2.2, etc.

foo at 1.0.0 doesn't really work since you can have two packages published 
to a repository, one with foo at 1.0 and one with foo at 1.0.0 and they're not 
considered equal FMRIs.

Whether that's a bug or not, I don't know, but it could mean quite a few 
changes "here and there."

-- 
Shawn Walker