Edward: > note that i'm not a member of the IPS team, a packaging expert, > etc. but i did buy the currently available fluendo codecs so > i'm replying because i'm an interested customer. ;)
Thanks for your comments. Some questions below... > well, when distinguishing between sparc and x86, it might be better > to use whatever the python equilivant for "uname -p" is, which should > return "i386" or "sparc". > > the problem with using "i86pc" vs "sun4u" (which is "uname -m") is > what about sun4v? (also, what about any other future platforms sparc > and x86 platforms that have a different "uname -m" identifier.) Good point. I'll recommend this to the codeina developers. >> We could set DISTRO="generic" and DISTRO_VERSION to "any", which are >> codeina's default values if it isn't necessary to differentiate. >> However, since Solaris and OpenSolaris have different packaging systems >> I think we might need to set DISTRO to "solaris" or "opensolaris". >> >> Is this correct? Or is it possible and advisable for Fluendo to just >> provide a single set of Solaris packages and install them in both >> Solaris and OpenSolaris? I know Fluendo would prefer this if possible, >> and avoid having to provide their code in different packaging system >> formats. > > IPS does have backwards compatibility for SRV4 packages, so > they could just release SRV4 packages for both solaris and opensolaris. > > that said, it would be much nicer if they had an IPS repo. i purchased > their codecs, so currently i get an email when there is an update to > them, then i go to their website, download them, and install the update. > if they had an IPS repo i could subscribe to it and just run the pkg(1) > command to download and install any new updates. of course since the > codecs are not free, this would assume some kind of subscription/login > authentication between my client and their IPS repo, which afaik is a > feature not yet available in IPS, but it is in the works. once it's > available i'd strongly recommend this approach. in the meantime i'm > surviving with the SRV4 compatibility. ;) That's good to know. What is the recommended interface to distinguish between Solaris Nevada versus OpenSolaris. For now, it might be good to recommend that the Fluendo codeina product differentiate between the two distros, but offer SVR4 packages for both until a later date when they could set up an IPS repository for OpenSolaris users. >> Assuming that isn't possible, and they need to provide different >> styles of packages for Solaris versus OpenSolaris, then what is the >> recommended interface to use to identify whether the codeina client is >> running on Solaris versus OpenSolaris? > > i'm not sure this distinction needs to be made. afaik, for all > the subsystems that fluendo should be dependant on, both solaris and > opensolaris will be delivering the same binaries in the same locations. > so they should be able to compile one set of binaries for use on both > platforms. the only difference would be in the packaging. Since the codeina application steps the user through the process of purchasing the plugins, then downloading and installing them, then the codeina client would obviously need to differentiate between the two since the installation process would be different (assuming that they decide to support an OpenSolaris IPS repository in the future). So, I am still wondering what the best interface for differentiating between a Solaris Nevada versus OpenSolaris client would be. Brian _______________________________________________ opensolaris-discuss mailing list [email protected]
