Re: [gobolinux-devel] Wrapper for Compile and InstallPackage
André Detsch wrote: > On 8/27/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >> I'm thinking of creating a wrapper script for Compile and InstallPackage >> so that one only has to gie one command to install an app. The >> application >> should be installed from recipe or from package depending on settings >> in a >> configuration file. This could later be used to update an app to the >> latest available version and maybe system wide updates. A bit like >> Manager, but for the prompt. Perhaps the script could wrap tools like >> DisableProgram and SymlinkProgram as well? ... I think it would be nice also with a cmdline option to choose source or binary. And/or even an interactive question: "Foo 1.0 is available in [S]ource and as a [B]inary package. Choose one:" >> My question is: what should it be called? >> git - GoboLinux Install Tool or perhaps gpm - GoboLinux Program Manager? > > Probably not good options, since they already being used by other > programs... > I don't have a good suggestion right now :-/ gtb - gobolinux tool box, gobotool, or maybe even just gobo? -- /Jonatan-=( http://kymatica.com )=- ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] Re: tools GoboHide/Resources/Tasks/GoboHide BuildLi...
Jonas Karlsson wrote: > On Mon, 28 Aug 2006 22:21:18 +0200, Carlo Calica <[EMAIL PROTECTED]> wrote: > >> On 8/26/06, Hisham Muhammad <[EMAIL PROTECTED]> wrote: >>> >>> I sympathize with your feeling. I felt like this for a long time. But >>> now I think all we can do is try to provide the best system we can and >>> hope that people will come to their senses. ;) >>> >> I feel adding the symlinks is part of providing the best system. >> There is little downside and they can help the transition for new >> experienced users. That said, we should avoid /opt, /media, and /srv. >> We don't have the equivalent and it would only cause confusion. >> > This is my point as well. There's no bad thing about adding symlinks, in > this case GoboHidden, as far as I can see, but they can be advantageous > when users migrate from other distros. They could also be helpful for > new linux users, if (when) we get such using GoboLinux, when they can > read suggestions and pointers posted for other distributions as the > directories (symlinks) exist. > For /opt I'm unsure what to do, I don't even know what it's used for, > but I think that we should have directories corresponding to /media and > /srv. > Having a standard place where media mounts is a good thing, so that > users know where to look and such things can be integrated in gui, like > placing icons on desktop or similar. I really don't know where such > directory should be called or placed in GoboLinux, but I use /Mount for > that. I use /Mount/Media for my HAL-ivman-pmount setup to automount removable media. Then I have different static mountpoints directly under /Mount. What's /srv? -- /Jonatan-=( http://kymatica.com )=- ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] Re: tools GoboHide/Resources/Tasks/GoboHide BuildLi...
On Tue, 29 Aug 2006 01:52:22 +0200, Andy Feldman <[EMAIL PROTECTED]>
wrote:
On 8/28/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
Having a standard place where media mounts is a good thing, so that
users
know where to look and such things can be integrated in gui, like
placing
icons on desktop or similar. I really don't know where such directory
should be called or placed in GoboLinux, but I use /Mount for that.
I also use /Mount... isn't that the default location for the automatic
mount points after a Gobo install? It's not *just* removable media I
guess, but it does include it.
Same goes for files used by servers such as Apache and Subversion.
Perhaps
defining what /Files or /Depot are used for could help here. As it is
now
they aren't well defined imo. I use /Files for such, on my server.
Having
this defined would also help recipe creation, making it possible to
provide stub configuration files, that actually works out of the box,
and
that the users can find the newly installed files, i.e. apaches default
htdocs.
As I understood it, /Files is used for system files (i.e. -- the user
won't have any direct interaction with them, but it will be used by
system tools).
That's how I've understood it as well and that's what I think of apache
server root, SVN repositories etc to be. The user never directly interact
with those files but uses some sort of client to get them (web browser,
svn client etc). Sometimes one might want to edit the htdocs in webroot,
but that's no users job but the webmaster's job.
Actually even the users htdos lies under /Files, but the users interact
with them through a symlink in their home directory. This has two reasons.
First the user can set whatever permissions on their directory, without
have to worry that the webserver can read their htdocs and secondly (and
most important) this is a preparation for having the home directory
encrypted. If the user is not logged on the encrypted file system isn't
mounted and the webserver can't read the htdocs. Actually the users htdocs
could be under /Depot as well, but thinking of them as they are served by
apache and having them with the other htdocs felt natural.
/Depot is for the user to actually put files.
My /Files:
Codecs, Compile, Descriptions, Documentation, Fonts, Fortunes,
Plugins. I have very little cause to manually enter any of those
directories. Codecs, for example, is populated (if I choose) during a
Compile of MPlayer. Any changes to Fonts and the various other things
could be considered system configuration.
I have got the same structure as you, but on my server I also got WWW,
SVN, MySQL and Trac.
My /Depot:
Backups, Docs, Downloads, Packages, WWW, Wallpapers. WWW, Docs and
Packages were there by default, and Packages especially I don't
interact with so I would choose to put it in /Files by default. The
other directories contain my files that don't fit naturally in my
/Users dir, because they aren't associated with my user account. (This
is a single-owner computer, so I don't need to separate for example my
backups from anyone else's.)
I don't have WWW or backup here, but instead I have Media, which contains
my music and film.
You're right that it is not easy to tell which of those would host
Apache-type files (although currently it is /Depot by default).
I think that /Files should be default, as I said above, the users never
directly interact with the htdocs.
Other stuff:
"A package to be installed in /opt must locate its static files in a
separate /opt/ or /opt/ directory tree, where
is a name that describes the software package [...]."
Describe /Programs alright. The only difference is they seem to assume
only a single level of folders for /opt//bin.
Yes, that describes /Programs alright. But then, to have it the "correct"
way could be to have an /opt directory, like /usr is now, and that
symlinks with the name and version are created to point to the
corresponding program, i.e. /opt/HTTPD-2.0.59 -> /Programs/HTTPD/2.0.59,
just to have the single level directories in /opt. This is not even a
suggestion but just an idea on how it could be "solved".
Other directories like /boot and /mnt seem like a good idea to me.
/mnt points to /Mount/Temp ("for a temporarily mounted filesystem"),
and /boot to /S/K/B. /srv points to wherever the WWW directory resides
by default (currenty /Depot, although if /srv pointing to /Depot seems
nonsensical I would argue that it's WWW which should move.) /etc/opt
points to /etc, /home points to /Users... And it doesn't make a
difference to native Gobo users if it's hidden.
Agree with you fully on all this, and I really like the idea of
/Mount/Temp for temporarly mounts instead of having them directly in
/Mounts, with an addition: /root should point to /Users/
(I have actually installed a program requiring the existance of /root).
--
/Jonas
Using Opera's revolutionary e-mail client: http://www.opera.co
Re: [gobolinux-devel] Wrapper for Compile and InstallPackage
On Tue, 29 Aug 2006 11:26:35 +0200, Jonatan Liljedahl <[EMAIL PROTECTED]> wrote: André Detsch wrote: On 8/27/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: I'm thinking of creating a wrapper script for Compile and InstallPackage so that one only has to gie one command to install an app. The application should be installed from recipe or from package depending on settings in a configuration file. This could later be used to update an app to the latest available version and maybe system wide updates. A bit like Manager, but for the prompt. Perhaps the script could wrap tools like DisableProgram and SymlinkProgram as well? ... I think it would be nice also with a cmdline option to choose source or binary. And/or even an interactive question: "Foo 1.0 is available in [S]ource and as a [B]inary package. Choose one:" Yes, the behaviour should be totally configurable using primarily a file. For example, I would set it to use recipes if the recipe and package versions are the same or when the recipe version is later. Is the package version later, the tool should present the recipe and package versions and ask me which I want to use. Some other users might want the binaries most of the times and should have it the other way around. There should be an option to have it to always ask and so on. One should also be able to change the default behaviour set in the conf file using command line options, for instance when one knows what alternatives there exist and one already knows that one wants to install the recipe (or package). My question is: what should it be called? git - GoboLinux Install Tool or perhaps gpm - GoboLinux Program Manager? Probably not good options, since they already being used by other programs... I don't have a good suggestion right now :-/ gtb - gobolinux tool box, gobotool, or maybe even just gobo? Having thought about it a bit more I came to the conclusion that one thing I like about GoboLinux, is the long and hard-to-type names (and ofcourse zsh's tab completion ;) ), so names like GoboInstall or GoboInstallTool is prefered (actually I wont choose an abbreiation unless it's very, very, very good). -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] Re: tools GoboHide/Resources/Tasks/GoboHide BuildLi...
On Tue, 29 Aug 2006 11:32:20 +0200, Jonatan Liljedahl <[EMAIL PROTECTED]> wrote: Jonas Karlsson wrote: On Mon, 28 Aug 2006 22:21:18 +0200, Carlo Calica <[EMAIL PROTECTED]> wrote: On 8/26/06, Hisham Muhammad <[EMAIL PROTECTED]> wrote: I sympathize with your feeling. I felt like this for a long time. But now I think all we can do is try to provide the best system we can and hope that people will come to their senses. ;) I feel adding the symlinks is part of providing the best system. There is little downside and they can help the transition for new experienced users. That said, we should avoid /opt, /media, and /srv. We don't have the equivalent and it would only cause confusion. This is my point as well. There's no bad thing about adding symlinks, in this case GoboHidden, as far as I can see, but they can be advantageous when users migrate from other distros. They could also be helpful for new linux users, if (when) we get such using GoboLinux, when they can read suggestions and pointers posted for other distributions as the directories (symlinks) exist. For /opt I'm unsure what to do, I don't even know what it's used for, but I think that we should have directories corresponding to /media and /srv. Having a standard place where media mounts is a good thing, so that users know where to look and such things can be integrated in gui, like placing icons on desktop or similar. I really don't know where such directory should be called or placed in GoboLinux, but I use /Mount for that. I use /Mount/Media for my HAL-ivman-pmount setup to automount removable media. Then I have different static mountpoints directly under /Mount. I liked Andy's idea better with media automounts directly under /Mount and temporarily mounts under /Mount/Temp What's /srv? /srv is for server files, like apache root htdocs, subversion repositories etc. -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
[gobolinux-devel] Dependencies and the recipe/package stores
I may have a way to make it possible to build a complete, recursive dependencies list in one shot at the beginning of compilation without having to prefetch every single recipe/package involved. I'm experimenting on my home server with an alternative layout of the recipe store. For each recipe, rather than just having the archive, I have a folder with the same name as the archive. Within that folder, I have the archive itself, and also the Resources folder extracted from it. A find on the directory for my Sudo recipe looks like this: ./Sudo--1.6.8p12-r2--recipe.tar.bz2 ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Sudo--1.6.8p12-r2--recipe.tar.bz2 ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/Defaults ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/Defaults/Settings ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/Defaults/Settings/sudoers ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/Environment ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/Wrappers ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/Wrappers/Sudo ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/Dependencies ./Sudo--1.6.8p12-r2--recipe.tar.bz2/Resources/BuildInformation In the parent directory of all of this, I have an .htaccess file with mod_rewrite set up to make requests for the folder itself give you the archive, so scripts don't have to be aware of my directory structure. wget "http://localhost/~drmoose/Sudo--1.6.8p12-r2--recipe.tar.bz2"; #gets the archive wget "http://localhost/~drmoose/Sudo--1.6.8p12-r2--recipe.tar.bz2/ Resources/Dependencies" #gets the dependencies Building directories like this is extremely easy to do automatically, and getting a dependencies list based on them should also be pretty simple. Just an idea. ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
[gobolinux-devel] Re: Wrapper for Compile and InstallPackage
On 8/29/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: On Tue, 29 Aug 2006 11:26:35 +0200, Jonatan Liljedahl <[EMAIL PROTECTED]> wrote: > André Detsch wrote: >> On 8/27/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >>> I'm thinking of creating a wrapper script for Compile and >>> InstallPackage >>> so that one only has to gie one command to install an app. The >>> application >>> should be installed from recipe or from package depending on settings >>> in a >>> configuration file. This could later be used to update an app to the >>> latest available version and maybe system wide updates. A bit like >>> Manager, but for the prompt. Perhaps the script could wrap tools like >>> DisableProgram and SymlinkProgram as well? > ... > > I think it would be nice also with a cmdline option to choose source or > binary. And/or even an interactive question: "Foo 1.0 is available in > [S]ource and as a [B]inary package. Choose one:" > Yes, the behaviour should be totally configurable using primarily a file. For example, I would set it to use recipes if the recipe and package versions are the same or when the recipe version is later. Is the package version later, the tool should present the recipe and package versions and ask me which I want to use. Some other users might want the binaries most of the times and should have it the other way around. There should be an option to have it to always ask and so on. One should also be able to change the default behaviour set in the conf file using command line options, for instance when one knows what alternatives there exist and one already knows that one wants to install the recipe (or package). >>> My question is: what should it be called? >>> git - GoboLinux Install Tool or perhaps gpm - GoboLinux Program >>> Manager? >> >> Probably not good options, since they already being used by other >> programs... >> I don't have a good suggestion right now :-/ > > gtb - gobolinux tool box, gobotool, or maybe even just gobo? > Having thought about it a bit more I came to the conclusion that one thing I like about GoboLinux, is the long and hard-to-type names (and ofcourse zsh's tab completion ;) ), so names like GoboInstall or GoboInstallTool is prefered (actually I wont choose an abbreiation unless it's very, very, very good). Another "unofficial" name convention is to use simple words for projects, like Compile, Manager, Freshen, Scripts, Bootstrap, etc (which I think sound good combined with GoboLinux when describing them unambiguously, such as "GoboLinux Compile", or even "Gobo Compile"). I liked Jonatan's suggestion of "gobolinux tool box", so my derived suggestion would be simply... Toolbox :) I think it sounds especially appropriate because the toolbox "carries" the other tools :) -- Hisham ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
