Yes today is confusing. The expectation is if we ship something with
our brand (the CD's) on it, then we should provide some support. We
have published information that specifically talk about the S10 distros
and companion CD support (I understand this does not mean anyone reads
or understands it). With the network repositories removing all
boundaries of shipping and media and encouraging people to publish
content to the repositories and that content should change more
regularly. It becomes even more confusing if we don't do something and
absence of information definitely does not help. Would be good if we
can make it even better that the current situation.
I agree that the HOTLINE/VENDOR in SVR4 is similar to what we are
needing, and also probably this has never been used in the past.
With the OSS licencing nature, "where bits come from" is not that
important in a physical sense. It may be the most important thing to
knowledge "where they come from" in a "who built and tested the bits"
sense. Maybe this can be taken from other metadata attributes and the
list be created outside of the packages.
The supported label is more a pre-deployment issue (people knowing they
can get support) and a entitlement issue when the customer gets
support. I would expect support engineers beyond tier 1 or 2 should
assume the product is supported and not have to do anything in this
space. Questioning the customer entitlement multiple times is a waste
of resolution time and money. The current methods of entitlement will
also probably not use this information effectively, but services that
require automated entitlement will need to be able to verify
supportability.
Brad
Darren J Moffat wrote:
Brad Vaughan wrote:
As part of moving from a physical media distribution to a LiveCD and
network repo's we have a little issue from the services side of people
understanding (expectations) what support and services are available for
a given piece of software (be it a package or consolidation).
That issue already exists today and there is already confusion on
support of packages on the Solaris CD vs Companion CD and where on
Solaris something is installed (eg /usr/sfw).
I would like to get included in the metadata definition a (or some)
attribute(s) associated with service delivery.
Depending on the intended use of the metadata (ie. end user
functionality/management/maintenance vs. development vs. system ) and
the ease of maintenance, the information types could be dramatically
different. I am going to assume the initial intended use is not end-user
related and difficult to maintain so I think initially we would limit to
a single attribute.
So it it isn't end-user related and it is difficult to maintain maybe it
isn't the correct solution to the problem.
BTW what is the real problem here ? I don't think it is that the pkg
repository is not "network" rather than on a CD but that there needs to
be a way to determine where given installed bits came from.
So if we could have a bit of information that communicated where to go
and get more detailed information (URL, Vendor Name, Contact Details, or
None).
So basically the same metadata that is already in SVR4 packages under
the VENDOR and HOTLINE fields ?
If I am wrong on my assumptions, then there are other data types that
would be useful for system management and support purposes.
I worked in support (Sun Service) and not once did I ever look at the
information in a package to determine if a command/utility/etc was
supported. So I see little value in this metadata in a package based on
my personal experience.
--
![]() |
Brad Vaughan
Software Services
Services Product Group
Sun Microsystems Inc
Phone x81869/+1-408-519-0898
Mobile +1-408-439-1507
Email [EMAIL PROTECTED]
|
|
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
