Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 03:32:40PM -0700, Donnie Berkholz wrote: Krzysiek Pawlik wrote: Use `quickpkg` before dangerous updates/merges. If something brakes - untar the package. Doesn't work too well when tar's broken too. =) How about statically linking a version of tar with portage. This way tar cannot be broken. Add an option to emerge, --backup or something similar, that will automatically run quickpkg. Then make a erescue executable that can parse the command line to figure out which package the user wants to be rescued from, and execute the new tar command. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpQUoBThCuhI.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote: On Sunday 15 May 2005 16:41, david stanek wrote: Add an option to emerge, --backup or something similar, that will automatically run quickpkg. If you set FEATURES=buildpkg, portage automatically makes binary packages for you. No need to add new support. That would build a binary package for the potentially broken package. What it would need to do is build a binary package of the existing merged package. So a user can recover from a botched upgrade. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpXNiuhdlWu3.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 09:56:54PM -0400, David Stanek wrote: On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote: On Sunday 15 May 2005 16:41, david stanek wrote: Add an option to emerge, --backup or something similar, that will automatically run quickpkg. If you set FEATURES=buildpkg, portage automatically makes binary packages for you. No need to add new support. That would build a binary package for the potentially broken package. What it would need to do is build a binary package of the existing merged package. So a user can recover from a botched upgrade. Actually a very simple safe-emerge script can be easily written. It could first do an 'emerge --buildpkg' on the existing merged package, if that package was already merged. The other part would be to create a statically linked version of tar that can be used in a recovery situation. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpvGsYgziGCW.pgp Description: PGP signature
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, May 15, 2005 at 09:07:15PM -0700, Sami Samhuri wrote: * On Sun May-15-2005 at 05:18:06 PM -0400, Mike Frysinger said: [...] my proposal is to implement a new utility (called 'erescue' for lack of a better name) that is written in C and designed to be statically linked ... then next time you break a core system package which cannot be recovered by simply running `emerge` a few times, you run `erescue broken package` Everyone who is saying that Portage can already sort of handle this seems to be missing one important point. If Python is broken then emerge won't work. The proposed erescue would still work in that case. If erescue is a statically built binary that basically untars a backed up copy of a package, why would it depend on Python? -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpxBL8wrNK4r.pgp Description: PGP signature
[gentoo-dev] Web application data
It seems that many web applications have a need to store data, logs, etc. I have been using a directory scheme I thought others on this mailing list may be interested in. Because of my need to keep things neat, clean and separate I do not like having this dynamic data in the same web directory that serves the application. For instance, my PyBlosxom ebuild has serveral CGI files that get installed when you use webapp-config to create a new instance of the application. I did not want the data and log files to reside in that same path. So what I did was create a hook script that webapp-config runs whenever it installs or removes and instance of the PyBlosxom application. The hook script creates a directory specific to that instance that is being installed. Given an instance of PyBlosxom served from the /blog directory you get this: /srv/fqdn/www/htdocs/blog /srv/fqdn/www/webapps/blog/data /srv/fqdn/www/webapps/blog/logs The structure allows the data to be separate from the application. This does not force the /srv heirarchy on anyone, the hook script uses the webapp-cofig environment variables so that things get installed where the user would expect them. To keep things separate I take this one step further. I also push the directory of the web application down a level. This separates content I generate from content that was installed for me. So my directory structure actually looks more like: /srv/fqdn/www/blog # PyBlosxom /srv/fqdn/www/mail # Squirrel Mail /srv/fqdn/www/htdocs# my content /srv/fqdn/www/webapps # web application data Does this seem reasonable? I was thinking about writing a GLEP or proposing an addendum to GLEP 11 or 20 to address this. My driving force behind this is a desire to have the application and the application data separate. As a side effect it is easier to do backups and my data between machines. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF pgpjRBaQMR1NQ.pgp Description: PGP signature
