* Brian Cameron ([EMAIL PROTECTED]) wrote: > > Glenn: > >>> I think your arguments are sound. It does seem that there should be >>> an interface for finding out if the user has a preference for IPS to >>> be used as the packaging system (beyond IPS just being installed on >>> the system). >> >> In theory, if a user wants to use IPS to manager their system they would >> have to configure IPS to use any repository other than the default. In >> this particular case, fluendo's. So, if fluendo creates an IPS >> repository and populates it the end-user will have to configure IPS on >> their system to look for that repository specifically. >> >> So, fluendo really doesn't have to do anything other than create an IPS >> repo in order to satisfy the installation needs of systems using IPS. > > Perhaps you misunderstand how codeina works, or I misunderstand > something. The codeina application autodetects when a user tries to > play a file that can't be played due to a lack of a codec. If Fluendo > offers a codec for sale that enables playing that format, it pops up > a window. The window steps the user through purchasing the plugin > (via a mozembed plugin accessing their webstore), then after purchase > it downloads the package and installs the plugins for you.
Yes, I've never used codeina on any platform it was available on. I always 'manually' installed whatever media support I wanted. That said, I can see it's attraction for less experienced users. > The idea is that the codeina application hides the hassles of the user > needing to figure out how to identify which plugins they need to buy > and how to deal with installing packages. Users just click purchase > and then the media starts working. Like magic. > > For this to work, I imagine that codeina client program would need to > know how to install packages and would need to have separate logic to > set this up for the user for IPS versus SVR4 packages, depending on > whether the user is running on Solaris or OpenSolaris. In other > words, the codeina client program probably needs to be enhanced to > know how to deal with installing IPS packages. > > Or am I missing something? It seems you are assuming that the user > should manually install the packages after purchasing them, which > sort of defeats the purpose of what codeina wants to do. So, in the case of IPS codeina would need to add their IPS repository to the system via a pkg(5) command. And then install anything they wanted out of that repository via other pkg(5) commands. > When I have used other popular operating systems, I have run programs > that similarly step you through installing a package without you needing > to do it by hand. Does IPS just not support this sort of feature yet? > I wouldn't think codeina would be the only program with the desire to > work this way. > >>> It also seems odd that there isn't a standard interface that can be >>> reliably used to differentiate between a Solaris and OpenSolaris >>> installation. Or some other OpenSolaris derivative, for that matter. >> >> That's a much bigger problem. And sort of out-of-scope to my mind. > > Agreed. I'm just surprised that it hasn't been thought through already, > I guess. I can't imagine Fluendo's codeina program is the only program > that would want to be able to differentiate between different distros > for various reasons. Therein lies the problem. You have to get all of the derivative distros to sit down and talk to each other and hash something out. Then you have to get new distros to abide by whatever the initial distros hammered out. It's a hard problem to solve. The Linux environment is a perfect example of how to get this wrong. :-) In the past, Solaris was pretty immune to the problem by virtue of their only ever being one distributor of Solaris. OpenSolaris changes the game and I don't think anyone's got this figured out yet. Though I've heard various people pay it lip service a few times since we launched. I don't recall all the background info, but I believe only Sun can call it's istro OpenSolaris (please, no flames. If I'm incorrect in that assumption a kind word to that effect is all that's required with appropriate documentation of course). >>> Without these sorts of interfaces, programs like codeina can't reliably >>> know when to provide IPS packages for end-users via a client >>> application. >> >> See, I don't think it should be about knowing when to provide packages >> in a particular format. It should be about providing packages that are >> going to work on a given system given that system's features. > > I'm unsure how the codeina program would be able to automatically > install packages in the right format if it can't tell what type of > packages to deliver for a given system. Right, there are two problems here. First figuring out 'what' to install, second figuring out 'how' to install it. >> As I >> said, Solaris 10 and OpenSolaris are very different in terms of feature >> set. Heck, the media players in Gnome shipped in Solaris 10 are *years* >> old at this point (from Gnome 2.0). If the plugins fluendo are going to > > GNOME 2.6 actually. I knew you'd know better than I :-) >> provide require features in those applications of recent vintage then >> they aren't going to work on Solaris 10. That's just an example. >> >> In the case of IPS vs SVR4, the problem is simple. There is currently >> no on-disk format for IPS packages. Everything comes from a network >> repository. So until an on-disk format is created (it's planned) a user >> will have to manually configure their system to point to a fluendo IPS >> repo to pull IPS formatted packages from. > > I'm not sure what you mean by manually. If the codeina client > application could set this up in the background for the user and > do whatever "manual" things are necessary to install the packages > then that would fit the codeina model better. > > Note codeina runs in the background of the user session, so it could > likewise probably be enhanced to notice when updates are available > and just update the package automatically when needed. > >> Were I fluendo, I'd figure out what my target markets were and then >> develop for that. Solaris 10 is one platform. > > They won't be targetting Solaris 10. Their plugins only work with > GStreamer 0.10. Solaris 10 ships GStreamer 0.8. So their target > market is Solaris Nevada based distros (such as Solaris Express) and > OpenSolaris. Ok, so that solves the 'what' to install. They'll need a check to make sure that the platform they are installing on has Gstreamer 0.10. I'm sure there's some way to do that reliably either via pkginfo (SVR4) or pkg (IPS) if not by some sort of gst-info invocation. >> OpenSolaris/Indiana is >> another. They are distinct platforms and will have differing features. >> If they can make their software work on both with one set of packages >> regardless of the format of those packages that's great (though I doubt >> it). Tell them to create SVR4 packages in that case and they're safe >> until we phase out SVR4 support entirely (if we even do that which I've >> not heard any plans of doing but it could happen I suppose). If they >> have to have seperate packages anyway because of the differences, then >> create SVR4 for Solaris 10 and IPS repo for OpenSolaris. > > I suspect it's not a problem for them to provide the plugins in IPS > or SVR4. However, their codeina application wants to just take care of > installing the package for you. I'm not sure how this can work if > codeina can't figure out what package system you are using. Right, on OpenSolaris (indiana) this is an issue because it supports both SVR4 and IPS because we're transitioning from one to the other. > Also, since they only want the plugins to be made available to users > who have paid for them, they need IPS to support some authentication > mechanism so only customers with assigned passwords could access the > plugins. I'm not sure IPS currently provides this sort of feature. Right, I don't believe IPS supports authenticated repositories yet. I do know that it will eventually. > Or perhaps IPS is just not something that works well with the codeina > model of trying to install packages for the user from a client program. > I'm unsure, and trying to get a better feel for this. I wouldn't say that, it could work with the above mentioned caveat. > As you say, since SVR4 is supported in both Solaris and OpenSolaris, > that probably makes the most sense for now. They can always switch > to an IPS model later, and hopefully by then we might have better > answers for how it might integrate with a program like codeina. I agree. I'd just plan for SVR4 for now and then they can migrate later once IPS is more fleshed out in it's capabilities (which we'd certainly need before we could consider shipping OpenSolaris without SVR4 support anyway I'd think). Cheers! Glenn _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
