On Sun, Apr 29, 2012 at 2:02 PM, Jérémie Burtin <jere...@jeremieburtin.fr> wrote: > On 24/04/12 19:09, Charlie Smotherman wrote: >> >> yes but ampache does depend on libapache2-mod-php5 which will pull in >> apache2 even though the package does not directly depend on apache2 > > I disagree, it depends on libapache2-mod-php5 | php5-cgi | php5 . >
So what's your point? > >>>> However with the upcoming Apache2.4 transition Ampache's packaging >>>> will only support Apache2. I am contemplating splitting the package >>>> into ampache-common and ampache-apache. >>>> >>>> Ampache-common would be for users such as yourself which want to use >>>> Ampache on webservers which are not supported in the packaging. This >>>> will also allow users to setup ampache in VM's, LXC's or what ever >>>> where the installation of a webserver in not desired. >>>> >>>> Splitting the package will also allow motivated community members to >>>> develop there own packages for their favorite webserver ie: >>>> ampache-nginx or ampache-monkey or ..... >>>> Trying to support multiple webservers has IMHO made the maintainer >>>> scripts overly complicated and splitting the package would >>>> significantly simplify the maintainer scripts. >>> >>> I think there should not be any web servers support. The user should be >>> able >>> to install ampache, whatever he's webserver is. No ampache-apache2, no >>> ampache-nginx... Only ampache. The very best could be some example >>> configuration files (see redmine package, containing configuration files >>> for >>> lighttpd, apache2, nginx... in /usr/share/redmine/example/). Then the >>> user >>> can use it, or write his own configuration file. >> >> Then you would want to install ampache-comman and hack away to your >> hearts content. This is the idea behind ampache-common. No >> webserver, no config files, no debconf question, no symlinking to >> system libs, no setting up logging, no logrotation, **nothing**. The >> only thing ampache-common would do is install ampache into >> /usr/share/ampache/www per the webapps policy manual. > > What would be the difference with a simple "wget" ? :) > Less typing? easier to get security updates? The ampache-common package would remove (as the current package does) "Convenience copies of code", ie. libjs-prototype, libphp-phpmailer, libnusoap-php, libphp-snoopy, FreeMono-Medium.ttf. Please see section 4.13 of Debian Policy, as wget would not. Having ampache install the above mentioned files would be considered an RC bug, hence the designation "dfsg" ampache-common would also remove (as the current pacakge does) xspf_jukebox.swf and xspf_jukebox.fla. The last time I checked there are currently no tools in debian to compile xspf_jukebox.fla into xspf_jukebox.swf. Currently there is no way to tell if xspf_jukebox.swf is actually compiled from xsplf_jukebox.fla. Having ampache install these files would also be considered an RC bug. > >> Ampache-apache would be for users who are not that familiar with >> setting up mysql, php and apache2 (noobs) or lazy people such as >> myself who want to simply "apt-get install ampache" and just have it >> work. >> >>> I sincerely hope you won't choose to only package ampache with apache2, >>> which would be a big pain for non apache2 users. >> >> Once again ampache-common would allow non apache2 users to setup >> ampache the way they want, with the webserver they want. >> >> Right now this is the only idea I have to satisfy both power users and >> noob's alike. Nothing is set in stone so I am open to suggestions. > > I don't think you should maintain 2 packages. You could have one, maybe > asking during the installation process if the user wants the package to > configure itself for apache2. Is this possible ? > Your thoughts about me maintaininer 2 packages is duely noted and I will take it under advisement. You mean like the over complicated mess I have going on now trying to maintain the package so it supports apache2 lighttpd and mythbuntu in one package? Not to mention I have had people (through private channels) ask me to support other webservers, thus complicating the maintianer scripts even more. Hmmmm Not to mention I am also considering adding dbconfig-common support to the packaging so abusing debconf is a concern. Please see paragraph 6, section 3.9.1 of Debian Policy. I have been working on the package split and implementing the required changes needed for the apache2.4 transition. The maintianer scripts have went from a complicated mess to stupid simple (< 25 lines). Baring any problems with the upgrade path 2 packages is the way I will probably go. It makes the maintenance burden less for me, along with making the package more modular which fits more use cases. Best regards -- Charlie Smotherman Debian Contributor Ubuntu Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
