Re: Web applications specific issues
* sean finney (seanius@debian.org) disait :
> > here some support from the debian SGDB packages (e.g. that the mysql
> > init.d script look at a place if it has some action to perform at
> > startup). I know this won't solve the distant SGDB problem, but that
> > would be some good solution for the local ones, that is the most common
> > case.
>
> i think the simplest solution for how the webapp policy could handle the
> topic of databases is to defer to the previously mentioned db app
> policy, which already has a lot of work done on it. there's more than
> enough other stuff for us to focus on here.
Agreed. We should rely on dbconfig-common for every DB related issues.
> On Tue, May 03, 2005 at 02:06:07PM +0200, Pierre Habouzit wrote:
> > the fact is if you change some templates, you don't want the upgrade to
> > simply override them.
>
> well, i'd argue that they weren't templates in the first place.
What do you mean exactly? In the Bugzilla package, there are a set
templates files which have to be shipped with the package. I have a bug
report against the fact that when you customize those files, you will
lose your changes whenever you upgrade the package.
What would you answer to the bug submitter?
> > and AFAIK, rt is not that good, since it has no less than 3 packages in
> > debian, and I recall some guy explaining that it was really hard to
> > upgrade from one version to the next, and that was why there is 3
> > packages (v3, 3.2 and 3.4). IMHO, that is not a success story at all.
> > if every single webapp means a new package for each new minor
> > release ... we are driving into the wall.
>
> the problem with upgrades is definitely a problem, but is somewhat
> tangential to what i was discussing. rt uses an "overlay" system,
> where you can put a copy of a page in /usr/local/somewhere and modify
> it, and then when you access a page in rt, if a modified version of the
> page exists there it will use that instead of the default. the upgrade
> problems have more to do with rt changing the location of files or
> their api, not with the overlay concept itself. that said, it
> illustratees exactly why providing such a feature can be a problem.
Yes, that is the ideal solution to me. But such a feature is really in
the scope of upstream source. Requesting every package to provide such a
behaviour would hurt maintainers I think. We should find an alternate
solution when this feature of "layering" is not possible upstream.
> let's not talk about the tools before we finish figuring out what
> exactly we're trying to do :)
Indeed :-)
> > > - is cgi-bin obsoleted?
> /usr/lib/cgi-bin obsoleted. also, there's the whole arch-independant
> cgi issue.
Exactly, we have a real problem here, /usr/lib/cgi-bin/ should be used
according to the Debian Policy but /usr/lib should only contain arch
dependant files... That's a paradoxe we have to solve.
I see two solutions:
- Provide /usr/share/cgi-bin and update the policy to allow arch
independant files to go there.
- Allow the use of /usr/share/package for hosting arch independant
scripts (which is most of the time the case).
I prefer the last one, which could allow a simpliest packaging of a lot
of webapps (I moved the Bugzilla CGI in /usr/lib/cgi-bin/bugzilla and it
was a pain to make that possible...)
--
Alexis Sukrieh <sukria@sukria.net>
http://www.sukria.net
« Quidquid latine dictum sit, altum sonatur. »
Whatever is said in Latin sounds profound.
Reply to: