Is it intentional and safe for these packages to provide these Mono capabilities? Are the pairs of packages, which provide exactly the same things, interchangable at run-time? You know what can happen when Yum resolves a dependency by pulling in the pkg with the shortest name...
banshee provides mono(Boo.Lang) = 0:1.0.0.0 boo provides mono(Boo.Lang) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386 required by: banshee - 0.13.1-1.fc8.i386
banshee provides mono(Boo.Lang.Compiler) = 0:1.0.0.0 boo provides mono(Boo.Lang.Compiler) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386 required by: banshee - 0.13.1-1.fc8.i386
banshee provides mono(Boo.Lang.Parser) = 0:1.0.0.0 boo provides mono(Boo.Lang.Parser) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386
banshee provides mono(ipod-sharp) = 0:0.0.1.0 ipod-sharp provides mono(ipod-sharp) = 0:0.0.1.0 required by: banshee - 0.13.1-1.fc8.i386
banshee provides mono(ipod-sharp-ui) = 0:0.0.1.0 ipod-sharp provides mono(ipod-sharp-ui) = 0:0.0.1.0 required by: banshee - 0.13.1-1.fc8.i386
banshee provides mono(NDesk.DBus) = 0:1.0.0.0 f-spot provides mono(NDesk.DBus) = 0:1.0.0.0 required by: f-spot - 0.4.0-2.fc8.i386 required by: banshee - 0.13.1-1.fc8.i386
banshee provides mono(Boo.Lang.Interpreter) = 0:1.0.0.0 boo provides mono(Boo.Lang.Interpreter) = 0:1.0.0.0 required by: boo - 0.7.6.2237-12.fc7.i386 required by: banshee - 0.13.1-1.fc8.i386
db4o provides mono(Mono.Cecil) = 0:0.4.3.1 monodevelop provides mono(Mono.Cecil) = 0:0.4.3.1 required by: db4o - 6.1-2.fc7.i386
db4o provides mono(Mono.GetOptions) = 0:2.0.0.0 mono-core provides mono(Mono.GetOptions) = 0:2.0.0.0 mono-core provides mono(Mono.GetOptions) = 0:1.0.5000.0 required by: f-spot - 0.4.0-2.fc8.i386 required by: mono-debugger - 0.31-2.fc7.i386 required by: mono-devel - 1.2.4-2.fc8.i386 required by: db4o - 6.1-2.fc7.i386
f-spot provides mono(Mono.Addins.Gui) = 0:0.2.0.0 tomboy provides mono(Mono.Addins.Gui) = 0:0.2.0.0 required by: tomboy - 0.8.0-1.fc8.i386 required by: f-spot - 0.4.0-2.fc8.i386
f-spot provides mono(Mono.Addins) = 0:0.2.0.0 tomboy provides mono(Mono.Addins) = 0:0.2.0.0 required by: tomboy - 0.8.0-1.fc8.i386 required by: f-spot - 0.4.0-2.fc8.i386
mono-core provides mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 nant provides mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0
On Thu, 2007-09-20 at 01:29 +0200, Michael Schwendt wrote:
Is it intentional and safe for these packages to provide these Mono capabilities? Are the pairs of packages, which provide exactly the same things, interchangable at run-time? You know what can happen when Yum resolves a dependency by pulling in the pkg with the shortest name...
I guess this is because some mono app ship dlls instead of depending on system versions of them?
Ideally we shouldn't do this, but i'm sure there are cases where its not possible to avoid. Maybe the mono auto-provides should only be looking in the public directories for dlls to auto-provide?
On Thu, 2007-09-20 at 09:11 +0200, Alexander Larsson wrote:
On Thu, 2007-09-20 at 01:29 +0200, Michael Schwendt wrote:
Is it intentional and safe for these packages to provide these Mono capabilities? Are the pairs of packages, which provide exactly the same things, interchangable at run-time? You know what can happen when Yum resolves a dependency by pulling in the pkg with the shortest name...
I guess this is because some mono app ship dlls instead of depending on system versions of them?
Ideally we shouldn't do this, but i'm sure there are cases where its not possible to avoid. Maybe the mono auto-provides should only be looking in the public directories for dlls to auto-provide?
It's certainly not unheard of for different packages to provide the same implementation of an interface. In fact, we should probably start thinking of coming up for solutions for such a scenario. The alternatives system is an example. Multiple implementations should be allowed to co-exist on the system. Luckily mono seems to have a way to choose which DLL it wants to use (probably first in the GAC or whatever). The question is _"How should this be treated in package management?"_ (which is Fedora's concern).
Perhaps the user should be given the option to choose which implementation or package to install? Maybe priorities can be assigned to packages whose sole purpose is to actually provide that interface implementation (as opposed to packages which happen to just use them).
Let's take JVM's, for instance. I can have several packages which actually provide JVM implementations, and I can also have Java apps that might want to package a JVM along with the app. Unlike mono, the choice of which JVM or JAR file to use depends on the alternatives system or might be overridden by the application.
Or take Firefox. Maybe a firefox package out there could come with it's own xulrunner implementation (which it currently does) or it could come without it and require one to already be on the system.
On a slight tangent: I wonder how effective the alternatives system really is and if mono might not be coerced to use it. It's interesting from a systems administration POV to either centralize control at some level (be it low-level like that or abstracted at a GUI level).
My thoughts are just rambling now. --
Richi Plana
On Thu, 20 Sep 2007 06:57:40 -0600, Richi Plana wrote:
It's certainly not unheard of for different packages to provide the same implementation of an interface. In fact, we should probably start thinking of coming up for solutions for such a scenario.
Technically, the different packages should only offer the same implementation of an interface if they make it available in a public place of the run-time environment where it is found by default by all components which may require a given implementation. General examples for such places are the dynamic linker's search paths for shared libraries [1], Perl/Python module directories, and most likely similar directories for Mono and other programming-language run-time environments. If, however, they store the implementation in a private directory, where it doesn't satisfy run-time requirements by default, they should not advertise the implemented interface [via the RPM system]. It bears the risk of breaking other packages like with this Perl module example: http://bugzilla.redhat.com/247113
On Thu, 2007-09-20 at 17:15 +0200, Michael Schwendt wrote:
On Thu, 20 Sep 2007 06:57:40 -0600, Richi Plana wrote:
It's certainly not unheard of for different packages to provide the same implementation of an interface. In fact, we should probably start thinking of coming up for solutions for such a scenario.
Technically, the different packages should only offer the same implementation of an interface if they make it available in a public place of the run-time environment where it is found by default by all components which may require a given implementation. General examples for such places are the dynamic linker's search paths for shared libraries [1], Perl/Python module directories, and most likely similar directories for Mono and other programming-language run-time environments. If, however, they store the implementation in a private directory, where it doesn't satisfy run-time requirements by default, they should not advertise the implemented interface [via the RPM system]. It bears the risk of breaking other packages like with this Perl module example: http://bugzilla.redhat.com/247113
Storing resources in non-systemwide defaults CAN work assuming that the underlying selection system supports it. For example, Java implementations can be stored in various subdirectories, but must be activated with alternatives. Libraries can be stored in private subdirectories if the package updates all user processes LD_LIBRARY_PATH environment variables to include them. One advantage of the latter approach is that the dynamic loader will search all the paths in LD_LIBRARY_PATH for the needed library whereas alternatives uses just one. It would be nice if some kind of priority system could be adopted (conceptually by rearranging the paths in the variable).
So I would agree with your statement with the slight modification that the package must actually enable said provisions system-wide.
I think in Windows (I haven't used Windows in ages so I'm just guessing), some packages use the approach where the library directory is added to the library search path. If that's what's used in mono and the mono packages, then it's probably safe to allow the Provide:.
Disclaimer: I don't actually use mono and am just guessing at the packages' implementation.
There was a certain beauty and elegance to the /opt/<package>/(bin|lib) system of yore. Too bad it was abandoned rather than integrated/improved. --
Richi Plana
On Thu, 2007-09-20 at 10:06 -0600, Richi Plana wrote:
There was a certain beauty and elegance to the /opt/<package>/(bin|lib) system of yore. Too bad it was abandoned rather than integrated/improved.
Come to think of it, if I were going to do things all over again, I'd probably allow for both system-wide installs into /usr as well as per-package installs in /opt/<package>/(bin|lib|perl5|python2.5| java-classpath|mono-libs).
Off-topic: is there a way to change a process's environment variables from a different process (but with the same UID or UID=root)? --
Richi Plana
On Thu, 20 Sep 2007 10:06:05 -0600, Richi Plana wrote:
Storing resources in non-systemwide defaults CAN work assuming that the underlying selection system supports it. For example, Java implementations can be stored in various subdirectories, but must be activated with alternatives. Libraries can be stored in private subdirectories if the package updates all user processes LD_LIBRARY_PATH environment variables to include them. One advantage of the latter approach is that the dynamic loader will search all the paths in LD_LIBRARY_PATH for the needed library whereas alternatives uses just one. It would be nice if some kind of priority system could be adopted (conceptually by rearranging the paths in the variable).
And then you end up with competing implementations of the same library interface. One with vulnerabilities, the other one with security-fixes. One with customisations and several minor releases behind, the other the latest release with bug-fixes. One built with a complete feature set, the other stripped down to upstream defaults. RPM dependencies would need to get much more complex if to cover such differences in implementations.
That's not something I'd like to see, at least not for system libraries. Using /etc/ld.so.conf.d/ (not LD_LIBRARY_PATH, which is empty by default btw) already is dangerous enough, since it can be used to avoid file conflicts and still insert competing libs into run-time linker's view. Further, there's no difference between "Provides" of libs in private paths and system-wide paths. It's too easy to disable/move the private paths and pull away the libs from the run-time env.
So I would agree with your statement with the slight modification that the package must actually enable said provisions system-wide.
Only then it may announce itself as being a provider of "something".
On Fri, 2007-09-21 at 10:14 +0200, Michael Schwendt wrote:
And then you end up with competing implementations of the same library interface. One with vulnerabilities, the other one with security-fixes. One with customisations and several minor releases behind, the other the latest release with bug-fixes. One built with a complete feature set, the other stripped down to upstream defaults. RPM dependencies would need to get much more complex if to cover such differences in implementations.
I don't see that as a problem of the system but the installed software. If anything, that's where the underlying selection mechanism might be useful. Vulnerabilities and other bugs are problems that need to be fixed. If an update arrives to fix a vulnerability, then I suggest it be installed with a higher priority than any other on the system, but if applications insist on using their buggy version, then that should be taken up with the application provider.
Why throw out the baby with the bathwater?
That's not something I'd like to see, at least not for system libraries. Using /etc/ld.so.conf.d/ (not LD_LIBRARY_PATH, which is empty by default btw) already is dangerous enough, since it can be used to avoid file conflicts and still insert competing libs into run-time linker's view. Further, there's no difference between "Provides" of libs in private paths and system-wide paths. It's too easy to disable/move the private paths and pull away the libs from the run-time env.
No, I didn't say it should be the only mechanism, but I believe there's a certain place for it. Support for it just has to be good. So far, the scenarios you've painted are due more to buggy implementations than anything to do with the strategy or philosophy of having multiple implementations on the system.
Having alternative code (whether it be several different JVM's on a machine, or several implementations of an MP3 codec) isn't bad per se. They just have to be supported properly by the system because anything it can't handle, the user ends up tweaking. Depending on how advanced the system is that's handling the multiple implementation subsystem, some users (advanced ones) might actually be alright (and in fact be more productive) with it, but others might not. But, again, that's a problem with the implementation that we, as software developers, can work on. --
Richi Plana
On Fri, 21 Sep 2007 08:39:25 -0600, Richi Plana wrote:
And then you end up with competing implementations of the same library interface. One with vulnerabilities, the other one with security-fixes. One with customisations and several minor releases behind, the other the latest release with bug-fixes. One built with a complete feature set, the other stripped down to upstream defaults. RPM dependencies would need to get much more complex if to cover such differences in implementations.
I don't see that as a problem of the system but the installed software. If anything, that's where the underlying selection mechanism might be useful. Vulnerabilities and other bugs are problems that need to be fixed. If an update arrives to fix a vulnerability, then I suggest it be installed with a higher priority than any other on the system, but if applications insist on using their buggy version, then that should be taken up with the application provider.
Why throw out the baby with the bathwater?
You want to insert another layer between installing system components and making them available system-wide after installation? Or a layer between the depsolver and the transaction set? Like "repo offers libfoo-2.0-1 and libfoo2-2.0-1, and user can choose either one or even both, and decide which to make available to apps"? Or you want packages to switch back and forth automatically between alternative implementations of the same interface? Redundancy instead of reuse. We don't talk about the same problem, I'm afraid. It is beyond my time to extend this thread much further and in pure text form into something completely theoretical that would require fundamental changes to the RPM dependencies system.
On Fri, 2007-09-21 at 18:06 +0200, Michael Schwendt wrote:
You want to insert another layer between installing system components and making them available system-wide after installation? Or a layer between the depsolver and the transaction set? Like "repo offers libfoo-2.0-1 and libfoo2-2.0-1, and user can choose either one or even both, and decide which to make available to apps"? Or you want packages to switch back and forth automatically between alternative implementations of the same interface? Redundancy instead of reuse. We don't talk about the same problem, I'm afraid. It is beyond my time to extend this thread much further and in pure text form into something completely theoretical that would require fundamental changes to the RPM dependencies system.
You're right. I wasn't talking about the general case. I was postulating things for people who actually might find systems like that useful. I'm actually thankful that alternatives exist and am glad that no one has argued to have it removed with the argument that only one system should ever exist.
I am not arguing for time and effort be contributed to catering to this particular endeavor. I just ask that if something is useful to other people and not to others, then people should refrain from making non-constructive remarks. If people actually find it useful and worth discussing, then the thread will grow at its pace. If not, then just let it die out.
As for myself, I asked if anyone knows how to change a process's environment variable from outside that process. Or if there are other ways to effect a change in the run-time linker behavior for currently running processes (like shells) that might spawn new processes.
Perhaps fedora-devel isn't the appropriate list, but it does have the best people to answer. I've seen worse off-topic and non-technical discussions grow on the list. At least the questions I ask might be useful to some people or the general public sometime down the line. --
Richi Plana
On Thu, 2007-09-20 at 06:57 -0600, Richi Plana wrote:
On Thu, 2007-09-20 at 09:11 +0200, Alexander Larsson wrote:
On Thu, 2007-09-20 at 01:29 +0200, Michael Schwendt wrote:
Is it intentional and safe for these packages to provide these Mono capabilities? Are the pairs of packages, which provide exactly the same things, interchangable at run-time? You know what can happen when Yum resolves a dependency by pulling in the pkg with the shortest name...
I guess this is because some mono app ship dlls instead of depending on system versions of them?
Ideally we shouldn't do this, but i'm sure there are cases where its not possible to avoid. Maybe the mono auto-provides should only be looking in the public directories for dlls to auto-provide?
It's certainly not unheard of for different packages to provide the same implementation of an interface. In fact, we should probably start thinking of coming up for solutions for such a scenario. The alternatives system is an example. Multiple implementations should be allowed to co-exist on the system. Luckily mono seems to have a way to choose which DLL it wants to use (probably first in the GAC or whatever). The question is _"How should this be treated in package management?"_ (which is Fedora's concern).
I'm not sure these packages *actually* provide the things they say they do though. (Although I haven't looked at it.) I think they keep local per-app versions of some dlls in non-public directories. This means other apps will never pick up these dlls. However, the auto-provides finds them and marks the rpm.