From: Stef B. <st...@gm...> - 2010-10-28 17:03:37
|
Hi, as developer of GoboLinux, I would like your advise on how to build a Programs folder. With GoboLinux, it was the system which maintained the Programs folder, with for every program installed a dedicated directory, inlcuding versions. Now one of my goals is to create something simular, using fuse. The way to create an environment like: Computer Network Personal Programs System or something simular is different. Instead of creating the system directories like /bin, /dev etcetera by symb. links, I will take the following steps: a. create a special directory %chroot% b. mount the fuse module to it c. create the above subdirectories (thus: Computer, Network etc.) d. create the directories bin, dev, etc, home.. and make the hidden. (this is already possible with my fs) e. redirect %chroot%/bin to /bin via the fusemodule or via mounting with --bind. Now chroot into this %chroot%. I had some working examples already, only text. It is a very challenging task to make this work. One of the things is the performance. The fuse module is an extra layer, of course this will result in performance loss. But what I want to ask you, how to setup a Programs folder when you have a "regular" system. Are there scripts to gather all the information about a package, for example firefox, and possibly more versions. Thanks in advance. Stef Bon |
From: Stef B. <st...@gm...> - 2010-10-29 07:00:28
|
2010/10/29 James Rhodes <jr...@ro...>: > On Fri, Oct 29, 2010 at 4:03 AM, Stef Bon <st...@gm...> wrote: >> >> Hi, >> >> as developer of GoboLinux, I would like your advise on how to build a >> Programs folder. >> > > A "regular" system? You mean, a system already managed by a package > manager? You can't do that because the package manager manages the files > and moving them or rearranging them would most likely cause it to go bonkers > (not to mention it would still not let you have multiple versions). You > need to have a separate package management system that is aware of such a > layout (for example, AppTools). > Regards, James. > Yes of course when moving an rearranging it will get you troubles with the existing packagemanager. And moving is not what I meant. I would like to have a folder with programs, and it may have symbolic links. For example: ls /Programs/Samba 3.5.0 Current -> 3.5.0 Settings ls /Programs/Samba/3.5.0 bin doc etc include lib man and ls /Programs/Samba/3.5.0/bin findsmb -> /usr/bin/findsmb nmbd -> /usr/sbin/mmbd net -> /usr/bin/net nmblookup -> /usr/bin/nmblookup ntlm_auth -> /usr/bin/ntlm_auth rpcclient -> /usr/bin/rpcclient smbd -> /usr/sbin/smbd swat -> /usr/sbin/swat ... .. an so on and ls /Programs/Samba/3.5.0/include libsmbclient.h -> /usr/include/libsmbclient.h Thus what I'm looking for is a way to determine : a. all the packages b. the files of that package, the type (executable, include file, doc, library...) c. the locations where these files are installed Well this is not so hard I think. The packagemanager commandline tools will offer such information. I'm just asking here someone has such a script. Stef |
From: Stef B. <st...@gm...> - 2010-10-29 07:32:32
|
2010/10/29 James Rhodes <jr...@ro...>: > On Fri, Oct 29, 2010 at 6:00 PM, Stef Bon <st...@gm...> wrote: >> >> 2010/10/29 James Rhodes <jr...@ro...>: >> > On Fri, Oct 29, 2010 at 4:03 AM, Stef Bon <st...@gm...> wrote: >> >> >> >> Hi, >> >> >> >> as developer of GoboLinux, I would like your advise on how to build a >> >> Programs folder. >> >> >> >> > >> > A "regular" system? You mean, a system already managed by a package >> > manager? You can't do that because the package manager manages the >> > files >> > and moving them or rearranging them would most likely cause it to go >> > bonkers >> > (not to mention it would still not let you have multiple versions). You >> > need to have a separate package management system that is aware of such >> > a >> > layout (for example, AppTools). >> > Regards, James. >> > >> >> Yes of course when moving an rearranging it will get you troubles with >> the existing packagemanager. >> >> And moving is not what I meant. >> >> I would like to have a folder with programs, and it may have symbolic >> links. >> >> Thus what I'm looking for is a way to determine : >> a. all the packages >> b. the files of that package, the type (executable, include file, doc, >> library...) >> c. the locations where these files are installed >> >> Well this is not so hard I think. The packagemanager commandline tools >> will offer such information. >> I'm just asking here someone has such a script. > > You don't even need a script. > (a) can be determined by simply grabbing a list of all of the folders that > exist within Programs; that will tell you all the applications that are > installed. (i.e. ls /Programs) > (b) can be determined by simply looking inside that Application's folder and > (c) can be determined by running 'ls -la' on the target file (ls -la > /bin/myprog will show the destination of the symbolic link) > That's generally the point of having the system laid out with folders > instead of package manager caches - you don't need to use obscure scripts or > know undocumented cache formats to find out the information you are looking > for. > Regards, James. You do not understand. I do not have the /Programs directory yet! I want to construct it, so doing a ls /Programs does not work! If I say to you I want to by a car, and I do not know how to get to the shop where they sell cars, you say it's smple, just take your car! Stef |
From: Stef B. <st...@gm...> - 2010-10-29 07:49:08
|
2010/10/29 James Rhodes <jr...@ro...>: > On Fri, Oct 29, 2010 at 6:32 PM, Stef Bon <st...@gm...> wrote: >> >> 2010/10/29 James Rhodes <jr...@ro...>: >> > On Fri, Oct 29, 2010 at 6:00 PM, Stef Bon <st...@gm...> wrote: >> >> >> >> Yes of course when moving an rearranging it will get you troubles with >> >> the existing packagemanager. >> >> >> >> And moving is not what I meant. >> >> >> >> I would like to have a folder with programs, and it may have symbolic >> >> links. >> >> >> >> Thus what I'm looking for is a way to determine : >> >> a. all the packages >> >> b. the files of that package, the type (executable, include file, doc, >> >> library...) >> >> c. the locations where these files are installed >> >> >> >> Well this is not so hard I think. The packagemanager commandline tools >> >> will offer such information. >> >> I'm just asking here someone has such a script. >> > >> > You don't even need a script. >> > (a) can be determined by simply grabbing a list of all of the folders >> > that >> > exist within Programs; that will tell you all the applications that are >> > installed. (i.e. ls /Programs) >> > (b) can be determined by simply looking inside that Application's folder >> > and >> > (c) can be determined by running 'ls -la' on the target file (ls -la >> > /bin/myprog will show the destination of the symbolic link) >> > That's generally the point of having the system laid out with folders >> > instead of package manager caches - you don't need to use obscure >> > scripts or >> > know undocumented cache formats to find out the information you are >> > looking >> > for. >> > Regards, James. >> >> You do not understand. I do not have the /Programs directory yet! I >> want to construct it, so doing a ls /Programs does not work! > > Then I don't understand what you expect the scripts to do then. You must > create a /Programs folder by building applications and libraries from source > and placing them in their own directory. You **must** ??? Who says?? My goal is to create a /Programs directory for a regular system, ie a system with the ordinary directories /bin, /etc, /lib etcetera where the packages are installed. Like I've mentioned before, the directory /Programs may contain symbolic links. You can look at it as a presentation of the software installed in a directory. > You can not retrieve such information from a package manager because it is > useless (you can't move the files to their own folder anyway, so a package > manager's representation of the system is of no use). Cannot?? As I remember rpm -qV gives lot of information... And again, yes I do not want to move packages. Stef Bon |
From: James R. <jr...@ro...> - 2010-10-29 08:01:58
|
> > > You can not retrieve such information from a package manager because it > is > > useless (you can't move the files to their own folder anyway, so a > package > > manager's representation of the system is of no use). > > Cannot?? As I remember rpm -qV gives lot of information... > And again, yes I do not want to move packages. If you aren't going to move the files and folders in the application's respective /Programs directory, then what is going to be stored in there? Symbolic links that point to the files in /bin, /usr, /etc..? Regards, James. |
From: Stef B. <st...@gm...> - 2010-10-29 08:52:34
|
2010/10/29 James Rhodes <jr...@ro...>: >> > You can not retrieve such information from a package manager because it >> > is >> > useless (you can't move the files to their own folder anyway, so a >> > package >> > manager's representation of the system is of no use). >> >> Cannot?? As I remember rpm -qV gives lot of information... >> And again, yes I do not want to move packages. > > If you aren't going to move the files and folders in the application's > respective /Programs directory, then what is going to be stored in there? > Symbolic links that point to the files in /bin, /usr, /etc..? Exactly, that's what I want. Stef |
From: James R. <jr...@ro...> - 2010-10-29 09:26:48
|
On Fri, Oct 29, 2010 at 7:52 PM, Stef Bon <st...@gm...> wrote: > 2010/10/29 James Rhodes <jr...@ro...>: > >> > You can not retrieve such information from a package manager because > it > >> > is > >> > useless (you can't move the files to their own folder anyway, so a > >> > package > >> > manager's representation of the system is of no use). > >> > >> Cannot?? As I remember rpm -qV gives lot of information... > >> And again, yes I do not want to move packages. > > > > If you aren't going to move the files and folders in the application's > > respective /Programs directory, then what is going to be stored in there? > > Symbolic links that point to the files in /bin, /usr, /etc..? > > Exactly, that's what I want. Oh, okay. In that case, you'll need to lookup the parameters for rpm, deb and any other package management systems you want to support. I doubt anyone has any scripts to do what you're asking, since I'd think it would be widely considered to be fairly pointless (it's only a filesystem representation of the state of the package manager, without actually providing any power to the user to modify it except through their existing package manager systems). That said, it's only a bit of text parsing and command-calling, so if you can manage writing a FUSE filesystem, I'm sure you'll find it really easy :) Regards, James. |
From: Lucas C. V. R. <lu...@go...> - 2010-10-29 10:27:35
|
On Fri, Oct 29, 2010 at 7:26 AM, James Rhodes <jr...@ro...> wrote: > On Fri, Oct 29, 2010 at 7:52 PM, Stef Bon <st...@gm...> wrote: > >> 2010/10/29 James Rhodes <jr...@ro...>: >> >> > You can not retrieve such information from a package manager because >> it >> >> > is >> >> > useless (you can't move the files to their own folder anyway, so a >> >> > package >> >> > manager's representation of the system is of no use). >> >> >> >> Cannot?? As I remember rpm -qV gives lot of information... >> >> And again, yes I do not want to move packages. >> > >> > If you aren't going to move the files and folders in the application's >> > respective /Programs directory, then what is going to be stored in there? >> > Symbolic links that point to the files in /bin, /usr, /etc..? >> >> Exactly, that's what I want. > > > Oh, okay. In that case, you'll need to lookup the parameters for rpm, deb > and any other package management systems you want to support. > > I doubt anyone has any scripts to do what you're asking, since I'd think it > would be widely considered to be fairly pointless (it's only a filesystem > representation of the state of the package manager, without actually > providing any power to the user to modify it except through their existing > package manager systems). That said, it's only a bit of text parsing and > command-calling, so if you can manage writing a FUSE filesystem, I'm sure > you'll find it really easy :) Indeed.. what we do in GoboLinux is rather different. Since we don't use RPM we have special tools responsible from building souce code and installing them in the expected prefix. We also have tools to create the symbolic links that will point to that program's bin, sbin, lib, etc. The same set of tools is responsible from finding optional and mandatory dependencies. That information comes along with the Recipes used to compile packages from source code and from text files shipped along with binary packages. The description we adopted for such files is rather simple. Each line says things such as "Glibc 2.4" or "Xorg 7.4". We know then that we need to have entries such as /Programs/Glibc/2.4 and /Programs/Xorg/7.4 to satisfy these dependencies. Stef, I think you will need to maintain a couple of helper scripts (if you don't already) to better interact with your file system. Bash or Python may be a good choice, especially because you will need to interact with the rpm tool to extract dependency information. Thanks, -- Lucas "If you're looking for a reason I've a reason to give: pleasure, little treasure" |
From: Stef B. <st...@gm...> - 2010-11-01 11:40:57
|
Thanks for the comments. a. what I want is nothing more than a folder with the programs installed. I want this because I like very much this from GoboLinux, and I'm developing a construction to provide something simular, but then on a conventional system, just like OpenSuse, Fedora, Mandriva and Ubuntu (and so on). I want to achieve that using a fuse module and a directory where the usersession is chrooted to. You read usersession, that's what I want to achieve. When the session for a user starts, the session will start in a special chrooted environment, which looks a lot like GoboLinux, where there are no directories anymore like /bin, /dev, lib etcetera. But this is a usersession only thing, the system is still running on the conventional environment... Right now I'm not that far, my construction provides the folders "Computer" (with hardware like USB and cdroms), "Network" (network shares) and "Personal" (with the folders "Documents", "Download", "Music" and "Video" etc..) in a subdirectory of the homedirectory. It's started using ConsoleKit, in parallel to the existing startup of the session (like a desktop environment KDE or Gnome). I'm working on this right now, a chrooted environment is something only to think of, although I had a prototype working on a consolelogin. Because running on a conventional system (aka not GoboLinux) this folder will indeed not have the "power" and features this folder (and the packagemanage system not to forget) has on a "real" GoboLinux system. That being said, this is a start. It's better than nothing, and maybe in future this map get's more integration... b. Creating this Programs folder is indeed not so hard. I've been asking here maybe someone has something like that, providing a way to handle the differences between the various packagemanagesystems. Stef |