hm. i missed the "codeina" part, which after some web searching, i guess it handles the finding, purchasing, downloading, installing, and updating of fluendo codecs? if so then cool. ed
On Fri, Oct 31, 2008 at 11:12:24AM -0700, Edward Pilatowicz wrote: > some comments below. > 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. ;) > ed > > On Fri, Oct 31, 2008 at 03:16:04AM -0500, Brian Cameron wrote: > > > > I am currently working with some engineers at Fluendo to help them > > provide their media plugins for OpenSolaris and also to help make > > the codeina program work on both Solaris and OpenSolaris. I have > > a few questions I am hoping you can help with. > > > > The codeina client program sets 4 variables to identify what system > > its running on. These are: OS, ARCH, DISTRO and DISTRO_VERSION. > > These don't need to all be set to unqiue values for each Solaris > > or OpenSolaris release, but instead only need to identify if Fluendo > > needs to ship different packages for a given system. So, in other > > words, DISTRO_VERSION probably only needs to be incremented if the > > packaging system or binary compatibly changes between versions. > > > > We were thinking it would make sense to set OS to Python's > > os.uname() value. It returns 'SunOS' as system name and 'i86pc' or > > 'sun4u' for Intel and Sparc architectures. This seems to be the > > same on both Solaris and OpenSolaris. So we were thinking of using > > these for the OS and ARCH values. Is this reasonable for both Solaris > > and OpenSolaris moving forwards, or should we be using some other > > more recommended interface? > > > > 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.) > > > 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. ;) > > > 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. > > > Any advise would be appreciated. It would be good to get the > > Fluendo codeina server/client set up properly now and avoid problems > > in the future. Then users will be able to download useful media > > and popular codecs from the Fluendo webstore via codeina easily. > > > > Note that Fluendo hopes to have MPEG-2 and MPEG-4 decoder codecs > > available for sale for Solaris by the end of the year. So that's > > exciting news. > > > > woot! :) > ed _______________________________________________ opensolaris-discuss mailing list [email protected]
