Hi Jack,
> 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. Ah ok, I see the issue. You are talking about the DC gui knowing not the installer gui. So, are you suggesting the user specify in the separate manifest what locales they want to install in the distro? What the current jumpstart and SXDE installer do... they allow the user to specify the locales they want to install. Then pfinstall->libspmi* goes off and grunges through the locale packages to get the list of those that is appropriate for installation. This works because the orchestrator can look at the installed miniroot and read directory entries to get the locale names for the gui to display. The reason this is necessary is because, as you know, the locale packages are not 1-1 to a specific locale. Right now they are group in 'region' and locale packages. The obvious issue with the DC is that the microroot isn't built at the time the user needs to choose the locales. Certainly a separate manifest with locale names would work. I would hope we could eventually come up with an automated way to glean locale data. > >> >>> 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. I think I am confused. What I was asking specifically was that the user will still be able to set things like default locale, and timezone, which is not from the initial image necessarily. So, in that sense the installed system is modifiable. Is this what you mean? > >>> 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? I don't know if keyboard types will go away. Right now there is a fixed list of available types. sysidkbd uses this list to display the types. The file this is in is /usr/share/lib/keytables/type_6/kbd_layouts. If there is a different keyboard type available then it would be under a different /type_xxx/ directory. They come from the SUNWkey package. So, we have a few choices as I see it 1) we hardcode the type values in to the DC GUI, 2) or we grep around in the ips pkg somehow to get the data that is in this package or 3) we ask the user to specify the data in a manifest. At some point we have to know where to look for this stuff. And we have to translate what the user specifies to a package or set of packages. thanks, sarah **** > > Thanks, > Jack >
