Matt Brown wrote: > Hi Thomas > > I wasn't aware of any out of date licensing info since I last trawled > the codebase and updated the copyright file - in anycase this metadata > is easy enough to bring to correctness now it is noticed.
I wouldn't be so optimistic about this one. I did few debian/copyright mistakes recently that makes me be a bit scared by copyright issues now. > The history of this package is that it has always had caretaker > maintainers and while we've done our best to keep it inline with > evolving policy requirements and best practices over the years the > upstream codebase certainly does not make that an easy task. As you have > yourself discovered. Yes, it wont be so easy, but still doable with few symlinks. > The upstream developers have promised me a new release in the next week > or two to address the PHP5.3 issues so my plan was to wait for that > before initiating any further action on my part. Chances are the release > team is unlikely to accept a brand new version into testing at this > stage so it is entirely likely that phpwiki will not be in our next > release. However i'd like to have the new phpwiki release in hand before > coming to a final conclusion here. Especially that you will have to package new things in Debian, like php-file-passwd that isn't currently in Debian. > With regards to the other open bugs and the package in stable. We have > users depending on it so I'm not really convinced that removal is in > their best interests. I would agree if there wasn't this PHP 2.02 issue. > If there are serious security issues as you hint > at then please file the appropriate bugs so we can address them through > the normal processes. I thought there was an issue with the shipped nusoap.php, but I think it's fine as it's protected by a .htaccess. I might be wrong though. I have sent another report still, and as well for the embedded PEAR libs. > The embedding of software in phpwiki is certainly sub optimal. But hard > to rectify without major changes from upstream. IMHO, this isn't something you can have the upstream do change for. This really is a packaging issue, not upstream. What you should do is create a +dfsg package that removes all the libraries, then create a symlink to the libs that are packaged in Debian. Best would be to script all this. I did that for the extplorer web file manager, and it worked well: the upstream can keep his embedded libs, which makes it possible to install the upstream tarball of phpwiki directly in an apache vhost without caring about installed libs, while the Debian package would still use separate libs. Whatever technique is chosen, I believe you should convince the upstream author to at least update his shipped libs, because right now they are quite outdated. > The bugs to separate out the dependencies and all RFH tagged and I would > gladly welcome patches - as would the upstream developers who are aware > of the issue but have limited time for such work. I would have limited time to work on it as well. If I was to work on packaging a wiki for PHP, I would rather do it for PmWiki that I like a lot (I have to say that I don't really know phpwiki...). I think it would be more reasonable to say that I will be able to help later on, after the release, but maybe not right now, unfortunately. > In summary - yes there is clearly much to be improved in the package and > the PHP issues will likely keep it out of the new release but I'm not > connecting convinced that a full scale package removal from the archive > is justified as you conclude. How will you fix the legal issue with PHP 2.02 of phpwiki in Lenny then? I know, all this does hurt, but I don't think we have a choice... :( > The issues are being worked on, but as > usual more hands are needed to make it happen at the speed we desire. We all have limited time, and days have only 24 hours... :/ Thanks already for the time you took replying to this bug report, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
