OpenCSW Bug Tracker


Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003894 [pkgutil] regular use minor always 2009-09-14 11:16 2013-01-02 16:32
Reporter skayser View Status public  
Assigned To bonivart
Priority normal Resolution fixed  
Status closed  
Summary 0003894: pkgutil 1.7: -L option only works with the package name, not the software name
Description Most other command options work with both (pgk and sw name), the new -L option only seems to work with the sw name. Can we get it to recognize the sw name too?

Example:

# pkgutil -L dhcp

# pkgutil -L CSWdhcp | head

/etc/init.d/cswdhcp
/etc/opt/csw/dhcpd.conf.CSW
/etc/rc1.d/K73cswdhcp
/etc/rc2.d/S73cswdhcp
/opt/csw/bin/omshell
/opt/csw/include/dhcpctl.h
/opt/csw/include/isc-dhcp
/opt/csw/include/isc-dhcp/boolean.h
/opt/csw/include/isc-dhcp/dst.h
Additional Information # pkgutil -v
1.7
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0006697)
bonivart (manager)
2009-09-14 13:50

Yes, I don't do lookups for that, I understand it would be usable since you can mix when doing installs for example. I'll try to add it.
(0006698)
bonivart (manager)
2009-09-14 19:42

I have added it in r102.

http://pkgutil.svn.sourceforge.net/viewvc/pkgutil/trunk/pkgutil?revision=102 [^]
(0006712)
skayser (administrator)
2009-09-17 12:02

Just tested it. What do you think about emitting a warning message if a sw/package name could not be resolved/found? Also, might there be some way to be less catalog-dependent when using the -L option?

I installed sudosh2 from testing/ and then omitted the -t option (i thought i was querying locally installed pkgs after all).

root @ ray42 ~# pkgutil-r102 -L sudosh2

root @ ray42 ~#

Putting the -t option back in makes it work.

root @ ray42 ~# pkgutil-r102 -t http://mirror.opencsw.org/opencsw/testing [^] -L sudosh2
Fetching new catalog and descriptions (http://mirror.opencsw.org/opencsw/testing/i386/5.10) [^] if available...
Fetching new catalog and descriptions (http://csw.informatik.uni-erlangen.de/csw/current/i386/5.10) [^] if available...

/etc/opt/csw/sudosh.conf.CSW
/opt/csw/bin/sudosh
/opt/csw/bin/sudosh-replay
/opt/csw/share/doc/sudosh2
/opt/csw/share/doc/sudosh2/AUTHORS
/opt/csw/share/doc/sudosh2/NEWS
/opt/csw/share/doc/sudosh2/README
/opt/csw/share/doc/sudosh2/changelog
/opt/csw/share/doc/sudosh2/changelog.CSW
/opt/csw/share/doc/sudosh2/license
/opt/csw/share/man/man1/sudosh.1
/opt/csw/share/man/man5
/opt/csw/share/man/man5/sudosh.conf.5
/opt/csw/share/man/man8
/opt/csw/share/man/man8/sudosh-replay.8
/var/opt/csw/sudosh
root @ ray42 ~#

Side note: There is always one blank line showing up first in the pkgutil -L output. Is this intended?
(0006713)
skayser (administrator)
2009-09-17 12:12

The same issue (omitting -t and then relying on sw -> pkg name resolution) can be seen with the -r option.

root @ ray42 ~# pkgutil -r sudosh2
Parsing catalog, may take a while...
Package sudosh2 not in catalog...exiting.
root @ ray42 ~#

I know this is a corner case, but again, from a user view point i would expect to be working with local packages, independent of which catalog i am running against.
(0006714)
bonivart (manager)
2009-09-17 14:26

I need to make a catalog lookup to find the package name since that's what's in the contents file. Otherwise I would need to extract the NAME-field from every package on the system with pkgparam or something and that would take minutes.

Pkgutil always uses package names internally, catalog names are just for convenience. In most cases it doesn't matter but with testing I suppose it does in a bad way.

If you have ideas I'm all ears.

The extra blank line is there to separate between files from multiple packages you may specify on the command line. That it's displayed when only one package is used is just me being lazy. It annoys me too and I will fix it...someday. :-)
(0006800)
bonivart (manager)
2009-10-05 18:45

The blank line is now gone. I have also omitted the catalog lookup if you use an argument that begins with uppercase which all package names should. That means if you use a package name from testing it will work but if you use the common/catalog name it will fail because the lookup will not find it (unless you use -t as well). So it's better but not good perhaps. For now I don't know how to fix this properly, if you use the common name it needs to parse the catalog to find the package name which is what's used in the contents file, as I said using pkginfo/pkgparam would be horribly slow.

Keep in mind that you can also use this for other packages than CSW:

# pkgutil -L SUNWzlib
/usr/include/zconf.h
/usr/include/zlib.h
/usr/lib/amd64/libz.so
/usr/lib/amd64/libz.so.1
/usr/lib/amd64/llib-lz.ln
/usr/lib/libz.so
/usr/lib/libz.so.1
/usr/lib/llib-lz
/usr/lib/llib-lz.ln
#

http://pkgutil.svn.sourceforge.net/viewvc/pkgutil/trunk/pkgutil?view=markup&pathrev=121 [^]
(0006834)
bonivart (manager)
2009-10-11 17:32

Maybe I could consult pkginfo/pkgparam only if the argument does not begin with uppercase characters and is not found in then catalog? Those two cases should cover most usage so the slowdown may be acceptable to get the rest.
(0009518)
dam (administrator)
2012-01-02 10:28

I suggest the following logic:
1. Look in catalog for matching catalogname and use corresponding package name on match
2. Use argument as-is otherwise
(0009796)
bonivart (manager)
2012-04-11 11:17
edited on: 2013-01-02 16:30

Isn't that what it does Dago?

# pkgutil -L foo (foo/SUNWfoo/CSWfoo not installed)
# pkgutil -L bash (CSWbash not installed)
# pkgutil -L SUNWbash (matches bash from SUNW)
/usr/bin/bash

(0010257)
bonivart (manager)
2013-01-02 16:32

I think I made a workable compromise here. Avoid catalog lookup when arg starts with uppercase (should be a package name), use catalog lookup for convenience otherwise.


Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker