hey, On Tue, May 03, 2005 at 04:56:24PM +0200, Pierre Habouzit wrote: > well, my proposition allow to do automatic processing. the current state > of web apps is frustrating in debian, since you have to do a *lot* > mannually. even if documented, that's painful. > > maybe I want to automatize too much, but I believe you want to > automatize too few ;) no, i just think there's a better approach that doesn't involve doing as much on the fs with symlinks and all that. keeping all this stuff in a webserver config file(s) seems a little cleaner to me. basically, what we'd need to do is document to the package maintainers how this works, and then they can provide templates for each type of install as part of their package. the admin can then run and play with these templates if they want to do anything not provided by default. if we had some kind of automagic system, it could then use these templates too. > > well, then you're furthering my point :). my concern with daemons is > > that the init scripts may not handle multiple instances of the daemon > > well. > > that's not a web-app centric. the problem is the same for any daemon in > debian (I have a lot of examples in mind) but ususally, those problems > are very specific to some peculiar uses of the apps. yeah but this is getting tangential to my point, which is that most web apps will fit just fine into a virtual host or subdirectory. > honnestly, I don't care if one upstream is frustrated because we won't > ship their package in stable. We may define the fact that if an app my concern isn't with upstream, it's with another d-d saying "to hell with your restrictions, i'm packaging this!". that kind of mentality would make it hard to make this a policy in the first place, and i expect no less from my fellow d-d's :) On Tue, May 03, 2005 at 04:53:30PM +0200, Alexis Sukrieh wrote: > 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? this is slightly different problem. if the user is *expected* to modify a file, it shouldn't be in /usr/share in the first place, or at least marked as a conffile. > 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. agreed. i think the alternate solution would be to tell them to rsync a copy of the tree into /usr/local and manage it themselves. if there were a standardized method/location for doing this, we could probably detect changes and splash a debconf message. however, we may be shooting both them and ourselves in the foot if we provide such a feature for them (think about someone "customizing" phpbb2 and having to work in the next phpbb update to their site). i think much of this could be addressed simply by providing the stylesheets/templates/etc as conffiles. > - Provide /usr/share/cgi-bin and update the policy to allow arch > independant files to go there. unfortunately, that won't work because you can't alias /cgi-bin to two directories, and it's likely that a web server will have both. there's a bug report on this that's like 3 years old. > - Allow the use of /usr/share/package for hosting arch independant > scripts (which is most of the time the case). yeah, that's along the lines of what i was thinking. still doesn't handle an application having both, but that could probably be handled better by the packager patching the locations in the webapp. sean --
Attachment:
signature.asc
Description: Digital signature