Install SMF's in standard locations

[Dagobert Michelsen]

Hi Carsten,

Am 27.01.2016 um 15:55 schrieb Carsten Grzemba <grzemba at contac-dt.de>:
> Some questions
> 
> 1. In Solaris11 is an SMF 'manifest-import' which can triggered if a new SMF is installed. But this SMF covers only the standard locations for SMF /lib/svc/manifest and /var/svc/manifest. I would prefer to use this SMF and install our SMF's also in standard location /var/svc/manifest.

I would also go with default locations.

> 2. Package Repositories: How want we handle our concept of catalogs unstable, testing, ... Want we cover this with different repositories/publishers?

I am not sure about this one, also not about the drawbacks of either solution.
It should be possible to mix and match packages from different catalogs.

> 3. Package naming: Our SVR4 packages use a "flat" namespace. IPS use a hirachical one but this is only cosmetics. There are aome lists of the relation of SVR4 and IPS names for some application like this:
> https://github.com/MrStaticVoid/spec-files-extra/blob/master/experimental/packagenames.sort_newnames.ts
> Should we keep the flat namespace and prefix with opencsw or also establish such hierachic?

library/ sounds useful, I would make that one automatic. Regarding the others I tend
to mimic the classification Oracle uses.

> 4. Packages for x86 and Sparc: IPS can deliver both architectures in one package. Has anyone some experience in building dual-arch IPS packages. Have we made the mgar platform target mandatory for that?

Right, I thought about that too, it should be fairly easy as GAR can already
build multiple trees for one package, however we don’t have one for Sparc *and*
x86 in one recipe. There are some adjustments in gar.conf.mk needed. But this
is definitely needed. Having one tree for Sparc and x86 is very important IMHO.


Best regards

  — Dago

--
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20160127/550dc690/attachment-0001.asc>