How about making it possible to login onto two different machines with the same account and home directory? I'm not sure with newer versions of Gnome then 2.2, but it really dosen't work well at all.
Your questions have been solved in another project called CUE. It haven't made much noise about itself.
Q. Do I have to add a bunch of crap to my $PATH? A. All environment is handled by an user application called HickUP. With this application you can even create multiple environments for one user which you can switch between as needed. It also has a project manager which allowes for good controlled development environments.
Q. Will it let me recompile critical applications, either to patch them or optimize them? A. All source are build from a single RPM for all build environments. The RPM environment is heavily controlled and demands more then usal RPM does. As an example it clears the environment and setups the environment based on dependency set in the RPMs spec file. Making the build environment the same everytime you recompile. Ofcause don't you have to install the RPMs on each computer on a large network, those times the sysadmin installs it on a NFS server and shares it to all the others. For all different OSes there is only a single RPM.
Q. What about apps with hardcoded pathnames? A. That haven't been much of a problem for most of those compiled. All configuration and application structure have been specified to be placed in/app and/env. For some server applications the configuration are placed below/etc/app. Logs and such below/var/log/app. Over the years of building and installing and using these application in CUE it haven't been many that have had this problems. In some cases a minor patch have been needed. The CUE concept have internaly also been building CUE RPMs for commercial applications with great success, license are handled by configuration in/env where each site can specify their own license server.
Q. What about libraries? A. The build environment when building the RPM controlls that we only use libraries from the CUE buildes or if it's a system library we allow that. Using the possibility to compile in the searchpath in each application/library for the libaray makes the application to find them without having to set the LD_LIBRARY_PATH.
Q. What about versioning? A. Libraries are keep in the same order as applications, one version in each directory.
Q. DND Saving? What's that? A. CUE haven't been made for end users yet on the installing part. The normal user in CUE uses the HickUP for choosing application. It was made for corporate environment for development environments from small project to distributed environments. That meaning a sysadmin are the one in controll of installing the application.
When having multiple application it's requires a strict building environment and disiplined builders to keep the quality high. Especialy when dealing with libraries.
The nice thing is that it was released by the main contributor with the GPL license. Other complaines have by that way been able to pich in and that saves alot on yor IT costs. By using signed RPMs it's also possible to know who contributed the RPM and that the build server was a valid one.
By using its own rpm it dosen't have any problems with systems already having rpm installed (normaly you don't use rpm but a wrapper script which fetches all depending rpms for the applications you want).
Slashdot Mirror
I wouldn't want to get spammed by that...
How about making it possible to login onto two different machines with the same account and home directory? I'm not sure with newer versions of Gnome then 2.2, but it really dosen't work well at all.
Your questions have been solved in another project called CUE. It haven't made much noise about itself.
/app and /env. For some server applications the configuration are placed below /etc/app. Logs and such below /var/log/app. Over the years of building and installing and using these application in CUE it haven't been many that have had this problems. In some cases a minor patch have been needed. The CUE concept have internaly also been building CUE RPMs for commercial applications with great success, license are handled by configuration in /env where each site can specify their own license server.
Q. Do I have to add a bunch of crap to my $PATH?
A. All environment is handled by an user application called HickUP. With this application you can even create multiple environments for one user which you can switch between as needed. It also has a project manager which allowes for good controlled development environments.
Q. Will it let me recompile critical applications, either to patch them or optimize them?
A. All source are build from a single RPM for all build environments. The RPM environment is heavily controlled and demands more then usal RPM does. As an example it clears the environment and setups the environment based on dependency set in the RPMs spec file. Making the build environment the same everytime you recompile. Ofcause don't you have to install the RPMs on each computer on a large network, those times the sysadmin installs it on a NFS server and shares it to all the others. For all different OSes there is only a single RPM.
Q. What about apps with hardcoded pathnames?
A. That haven't been much of a problem for most of those compiled. All configuration and application structure have been specified to be placed in
Q. What about libraries?
A. The build environment when building the RPM controlls that we only use libraries from the CUE buildes or if it's a system library we allow that. Using the possibility to compile in the searchpath in each application/library for the libaray makes the application to find them without having to set the LD_LIBRARY_PATH.
Q. What about versioning?
A. Libraries are keep in the same order as applications, one version in each directory.
Q. DND Saving? What's that?
A. CUE haven't been made for end users yet on the installing part. The normal user in CUE uses the HickUP for choosing application. It was made for corporate environment for development environments from small project to distributed environments. That meaning a sysadmin are the one in controll of installing the application.
When having multiple application it's requires a strict building environment and disiplined builders to keep the quality high. Especialy when dealing with libraries.
The nice thing is that it was released by the main contributor with the GPL license. Other complaines have by that way been able to pich in and that saves alot on yor IT costs. By using signed RPMs it's also possible to know who contributed the RPM and that the build server was a valid one.
By using its own rpm it dosen't have any problems with systems already having rpm installed (normaly you don't use rpm but a wrapper script which fetches all depending rpms for the applications you want).
-qick