[...]
> 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.
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.)
--
Vlad
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
