On 09/30/11 10:11 AM, Vladimir Marek wrote:
[...]
IIRC, the way IDRs are supposed to work is that each package in the IDR is
supposed to depend on a private package, which acts as a "key". That key
is delivered privately to the customer for whom the IDR is intended. When
they install they key, they will then be able to install the IDR which is
available in the normal support repository, and the normal sparse download
mechanism that IPS provides comes into play.
Alternatively, the IDR packages themselves can be made available to the
customer privately and completely, for redistribution on their own network,
at which point the cost of downloading the entire package is paid once, and
all other systems in their network retrieve only the changed files.
The RPE folks should have this well in hand. I don't see how userland
makes this more difficult than, say, ON, though the ability to
automatically add the IDR dependency based on an environment variable
might be nice.
Because the idr-create tool expects to have files in one or two proto
areas (in case you are building FAT idr containing both sparc and x86
bits). There is no such thing in userland.
To my knowledge, none of the consolidation build mechanisms build
multiple architectures and create FAT packages from one or more proto
areas. Each consolidation runs separate builds on all architectures and
then merged the resulting package repository (using pkgmerge) to
generate a set of FAT packages. Userland is no different in that
respect. Perhaps idr-create is generating it's own version of the WOS
packages from separate proto areas. That would seem prone introducing
package breakage (incorrect links, missing/extra files/directories,
incorrect attributes, ...)
Theoretically we could make userland to generate IDRs directly, but I
think that it's too much work (*). So instead I'll create a little
script which will convert the 'gmake publish' repo into proto-like
directory with installed files, so that the idr-create tool will be able
to run unchanged.
(*)
- the system would have to be able to work with both sparc and x86
repository at the same time
- the system would have to be able to work with several
packages/components at the same time (to form single IDR)
- someone would have to maintain the system if normal idr tools will
change in the future (automatic uploading to tracker etc.)
The idr-create tool(s) should really only have to deal with the
resulting FAT package repository generated by building and publishing on
all architectures and then merging the resulting architecture specific
repos. If it worked on this data, then it doesn't matter how you
generated the FAT package repo, only that you have one.
-Norm
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
