Hi Sarah.
>>
>> 1) Not sure what extra things DC needs to do to provide for a
>> live-image installable image or a repo-installable image. It will
>> need to include an installer, but how does that fit with the manifest?
>>
> Isn't this just an artifact of the installer, whether or not it
> intalls from an image or from a repo? So, wouldn't this just be the
> install pkg?
OK. I just answered the same question for Dave.
>> 2) Disk and network parameters for installation are still TBD.
>>
>> 3) There are some things which cannot be known by the DC but which
>> are needed by it. For example, if someone specifies they want a
>> certain locale, I don't want to hardwire into DC a package name
>> delivering that locale. For maintainability, these things will have
>> to go into a manifest. I'm thinking of putting them into a manifest
>> different than the one for user-specified parameters. That way if
>> the supported locale list changes, one can just upgrade their DC and
>> get the changes without worry of overwriting or having to merge the
>> user's existing user-specified parameter manifest.
>>
>>
> I think that the locale==pkg isn't correct. At least not with the
> direction the g11n folks are going. Just to keep that in mind. In
> general I am not sure why you would need to keep this in a different
> manifest. If the list of supported locales changes, the user still has
> to specify what locale(s) they want to install as part of the image,
> correct? So, they would have to modify their user manifest anyway.
It is true that the user will have to specify a list of packages to
install for their distro. However, how does DC know from the selected
packages, which locales are available for selection for either the live
image or the installer? This is why I thought a separate mapping would
be handy. If the SUNWwxyz package were installed, then locales ab_CD
and ef_GH would be available. But you'd never know this from looking at
the package name.
One alternate possiblility might be to scan the descriptions of
installed packages for a list of locales, assuming the locales are
listed in the package descriptions. But... no. What about installs from
a foreign repo? The GUI configurator tool would have to know before
being able to look at the package descriptions. Here, a package->locale
mapping would come in handy.
>
>> Assumptions:
>> ------------
>>
>> 1) When installing from the live image that all parameters are AS-IS
>> from the live image. (e.g. same users, files, locales, etc)
>>
>>
> Just to be clear, you are saying that what's on the image is what they
> get? Not that they can modify any of these during installation?
Well, yes... that's what I said originally.
But I will change this, and pass the same install params regardless of
whether the installer takes from the live image or the repo. If this
doesn't work for you or the AI team please let me know how I should
tweak the DC manifest to accommodate.
>> 2) A list of supported keyboard types is not included because all are
>> currently delivered in a single package and I assume it will stay
>> that way once packages are refactored (as keyboard map files are
>> small). This is not to be confused with locales which are included
>> in the manifest.
>>
>>
> We run sysidkbd right now, which gets the list of supported keyboards
> from the file on the system. What will replace the keyboard mechanism?
> And, will we need to list the supported keyboard types in the future?
OK. As I see it, we will need a maintainable and supportable way for DC
configuration GUI to get the list of supported keyboards so that it can
prompt and validate an entry, both for a live image and an install
image. The manifest validator should be able to get this info to
validate the manifest too. I'm not sure how this will work for remote
repos.
Do you think keyboard types will ever go away? Is it dangerous to
assume that they won't? While it would be best to get a list of
supported keyboards from the repo itself somehow, if we cannot do this
perhaps we can assume at least a full list of what we have today will be
there. What are your thoughts on how to resolve this?
Thanks,
Jack
