Bug 322 - Tagging doesn't work for 'set' action
: Tagging doesn't work for 'set' action
Status: RESOLVED FIXINSOURCE
Product: pkg
actions
: unspecified
: Other Solaris
: P3 minor (vote)
: ---
Assigned To: Bart Smaalders
: pkg/actions watcher
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2007-12-18 02:18 UTC by gerard
Modified: 2009-02-19 18:56 UTC (History)
6 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description gerard 2007-12-18 02:18:20 UTC
As part of UC efforts, we are trying to use the package attributes (via 'set'
action) to specify the configuration commands for various components. This
configuration command will be used later(after installing all packages) by the
installer/UC to fire the configurators. Since the configurator command for a
component can vary depends upon the platform, we're trying to see if
tagging/filtering approach can be applied for 'set' action to specify the
configurator command for varying platforms.

While evaluating, its observed that tagging/filtering doesn't work for package
attributes via 'set' action.

e.g

> pkgsend -s http://localhost:20000 add set name=description value="windows package"  os="windows"

Traceback (most recent call last):
  File "/export/home/jerry/usr/bin/pkgsend", line 307, in ?
    ret = main_func()
  File "/export/home/jerry/usr/bin/pkgsend", line 284, in main_func
    trans_add(pcfg, pargs)
  File "/export/home/jerry/usr/bin/pkgsend", line 159, in trans_add
    action = pkg.actions.fromlist(args[0], args[1:])
  File
"/export/home/jerry/usr/lib/python2.4/vendor-packages/pkg/actions/__init__.py",
line 137, in fromlist
    action = types[type](**attrs)
  File
"/export/home/jerry/usr/lib/python2.4/vendor-packages/pkg/actions/attribute.py",
line 53, in __init__
    assert len(attrs) == 2
AssertionError
Comment 1 Stephen Hahn 2007-12-18 07:00:45 UTC
If a package only supports one OS target, then this use case isn't meaningful.
Could you give another example of when a conditional attribute should be
needed,
and perhaps why one would use filtering, rather than, say, property suffixes, 
like "pkg.property.case1", "pkg.property.case2", etc.?
Comment 2 gerard 2007-12-19 01:23:40 UTC
This use case (as originally described in the bug) is primarily meant for the
cases where we would have one "fat" package that supports all platforms. In
that case, we just would like to depend on one package attribute (say 
 com.sun.application.configurator) and the same can be used by all the
components to specify their configurator command in a standard way. This is
prefered over property suffixes because both UC and the components don't have
to deal with multiple property attributes.
Comment 3 nouar38 2008-03-13 03:55:17 UTC
I'm adding myself in this bug to be notified if any change happens.
Comment 4 Tom Mueller 2008-03-21 11:15:21 UTC
Another use case for this would be to provide localized values for attributes
such as "description".
Comment 5 Danek Duvall 2008-03-21 13:09:01 UTC
When I first coded up attribute actions, it seemed like it might be a good idea
to allow people to specify them in either one of two ways:

    set name=<attribute name> value=<attribute value>

or

    set <attribute name>=<attribute value>

If you allow for arbitrary tags to be added, the latter syntax becomes
ambiguous.  I think that means that the latter syntax should be dropped, as
ultimately it doesn't provide that much of a benefit, and it's different from
how all other action attributes work, anyway.
Comment 6 Bart Smaalders 2009-02-19 18:56:36 UTC
Fixed in 845:3e2af0880c79

You must either have:

set <name>=<value>

or

set name=<name> value=<value> [value=<value>]

Had to change this for fat packages.