Mantis - pkg_get
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4317 regular use major always 2010-03-02 15:02 2010-03-03 11:14
Reporter: skayser Platform:  
Assigned To: bonivart OS:  
Priority: normal OS Version:  
Status: closed Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
Summary: 0004317: Behavior with noncsw=true packages on local mirror inconsistent with regular behavior
Description: Within our company we are using pkgutil configured against the current/ CSW branch as well as an in-house package repository. Just tried to upgrade a package from the in-house repo, but pkgutil didn't consider it as an update candidate although there is an updated package available (different version, same REV).

root @ ray42 ~# pkgutil -c --single fvwm_dtlogin
CONfvwmdtlogin 0.03,REV=2010.03.02 0.04,REV=2010.03.02
root @ ray42 ~# pkgutil -Ni fvwm_dtlogin
Parsing catalog, may take a while...
CURRENT packages: CONfvwmdtlogin-0.03,REV=2010.03.02

Nothing to do.


According to what you said, noncsw seems to be a patched in feature that's not properly integrated in the overall pkgutil architecture. Would be very helpful if it was :) Here is the excerpt from our IRC conversation WRT to that issue

14:35 <@skayser> bonivart: ping. got a funny pkgutil behavior :)
14:35 < bonivart> skayser, shoot
14:37 <@skayser> here goes: http://pastebin.com/kXH0VY8u [^]
14:37 <@skayser> doesn't upgrade a package from 0.03 to 0.04
14:37 <@skayser> bonivart: that's with noncsw=true packages
14:37 <@skayser> in case it matters
14:38 <@skayser> let me know if you need pkgutil -D output
14:39 < bonivart> do you have current plus your own mirror?
14:39 <@skayser> indeed i do
14:40 < bonivart> i guess it's a bug with noncsw, i was always skeptical of it but
                  several people wanted it and offered patches for it but there's
                  no real concept of it
14:41 < bonivart> there may be situations all over where it makes a difference :-(
14:41 < bonivart> could you file a bug please?
14:41 <@skayser> will do, thank you
14:42 < bonivart> what happens if you specify CONfvwmdtlogin-0.04,REV=2010.03.02 as
                  package to install? will it be ignored?
14:43 * skayser tries
14:44 <@skayser> "Nothing to do"
14:44 < bonivart> yes, but does it say that 0.03 is current or what?
14:45 <@skayser> bonivart: yes it does CURRENT packages:
                 CONfvwmdtlogin-0.03,REV=2010.03.02
Steps To Reproduce:
Additional Information: Observed with the revision 210 (upcoming 1.10 beta)

  # $Id: pkgutil 210 2010-03-01 19:16:46Z bonivart $

# ~skayser/bin/pkgutil-r210 -v
1.10b1
Relationships
Attached Files:
Issue History
Date Modified Username Field Change
2010-03-02 15:02 skayser New Issue
2010-03-02 15:58 bonivart Status new => assigned
2010-03-02 15:58 bonivart Assigned To => bonivart
2010-03-02 16:20 bonivart Note Added: 0007565
2010-03-02 16:20 bonivart Status assigned => feedback
2010-03-02 17:06 skayser Note Added: 0007566
2010-03-02 17:35 bonivart Note Added: 0007567
2010-03-03 11:14 bonivart Status feedback => closed
2010-03-03 11:14 bonivart Resolution open => no change required

Notes
(0007565)
bonivart   
2010-03-02 16:20   
I missed that the REV-field is the same for both packages. Note that -c isn't really "upgradeable" packages, it's more "packages that are different in one way or another".

To trigger an update the REV-field must be "greater". See http://pkgutil.wikidot.com/get-install-and-configure#toc8 [^] for the rules used to compare package versions.

Also note that more than YYYY.MM.DD is allowed so you can force an upgrade not only with a newer date but also with, e.g., 2010.03.02.1 if you don't like faking future dates. Or insert HH.MM if you like, 2010.03.02.16.20.
(0007566)
skayser   
2010-03-02 17:06   
Thanks for letting me know. I would have expected that a new version would be considered as upgrade (no matter what the REV field was). Is this intended behavior (not to be mistaken for known behavior) or should I file a new bug?
(0007567)
bonivart   
2010-03-02 17:35   
It is intended, we wanted to make the version field redundant, it makes for free use of like 4.5p3,REV=2010.03.02 instead of the long, ugly 4.5,REV=2010.03.02_rev=p3. It's very hard to correctly parse a mixture of digits and characters and find out which one is "greater". Is "b" just any character or short for beta and what does that mean compared to "a" and "c" and so on.

The documented implementation is based on a discussion between myself, Dago and James. You know it must be good if James agreed. :-)