Sean Sprague wrote:
> Hey Bart!
> 
> Thanks for the reply. Comments mainly at the foot...
> 
>> We should add a -v option like pkg list has, perhaps.  In any case,
>> pkg list -av SUNWts reports:
> 
> Possibly; but the RFE level is somewhere near "nit".
> 
>> : [EMAIL PROTECTED]; pkg list -av SUNWts
>> FMRI                                                             STATE 
>>     UFIX
>> pkg:/[EMAIL PROTECTED],5.11-0.86:20080426T180521Z                    known 
>>     ----
>> pkg:/[EMAIL PROTECTED],5.11-0.86:20080422T223257Z                    known 
>>     u---
>> pkg:/[EMAIL PROTECTED],5.11-0.79:20080205T170331Z                    known 
>>     u---
>> pkg:/[EMAIL PROTECTED],5.11-0.75:20071114T203942Z                    known 
>>     u---
>> : [EMAIL PROTECTED];
>>
>> There are indeed two versions of the build 86 pkg; we decided not
>> to delete the first version (which was part of release candidate 2).
> 
> Absolutely fair.
> 
>> In the future, republication will be more incremental, and only packages
>> with real changes will get multiple versions. 
> 
> Equally reasonable.
> 
> Playing devil's advocate, I tried to install an earlier version from the 
> repository, and came unstuck; and I think that I smell a rat...
> 
> If I try to pkg install the latest version of SUNWts .86 by specifying 
> its full FMRI, it installs fine. If I try to install the previous 
> datestamped version of .86 by specifying its full FMRI, it installs 
> fine. If I try to pkg install an earlier version (.79 or .75) by 
> specifying its full FMRI, I get a python traceback which ends in the text:
> 
> NameError: could not retrieve manifest '[EMAIL PROTECTED]' from 
> 'http://pkg.opensolaris.org:80'
> 
> So I suspect that when I install successfully either of the .86 
> versions, only the current/latest one is actually installed (and not the 
> earlier-datestamped version when I specify its full FMRI); and when I 
> try to install a version prior to .86, it tries to install the .86 
> version, but somehow the FMRI gets munged from containing a "," to its 
> ASCII "%2C", which provokes a barf.
> 
> Obv pkg is largely aimed at maintaining the latest versions of packages, 
> but for regression testing previous ones need to be available (as they 
> are; just I can't get ahold of any ;-) ). Obv also, this is a singleton 
> case, and may not in the slightest reflect on other packages (TX being 
> an awkward sausage at the best of times ;-) ).
> 

There's a bug there.... I'm looking for it. The incorporation (pkg named 
entire)
forces the downrev package up-to-date, but there's a problem w/ fetching
the manifest.  Investigating...

- Bart


-- 
Bart Smaalders                  Solaris Kernel Performance
[EMAIL PROTECTED]               http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss

Reply via email to