On Fri, 2008-04-11 at 18:20 +0200, Jan Hauke Rahm wrote: > Dear mentors, > > I'm working on a package that includes some php libs Do you like making life difficult for yourself or are you just looking for a challenge? "PHP is easy" is a myth. Bad PHP is trivial. Good PHP can be very, very difficult (and is never "finished"). You'd better have lots of time and good experience of hacking PHP to get this off the ground. There are at least three red flags in your message - comments and questions the belie an undercurrent of worries about whether this package is a good one to pick. It may be fine, but you may need to tread quite carefully to get this one off the ground. > (e.g. pear > packages). Some of those are already packaged for debian Those that are not already packaged for Debian should be packaged for Debian from the original pristine source. You should expect to file ITP's for all of those and maintain them yourself (or with others as part of an existing team in Debian) as dependencies of your main package. Do not upload (or seek a sponsor) for the main package until these dependencies are available in Debian. Persuade upstream to adopt the upstream maintenance of any existing Pear packages that may have died upstream. After all, if your upstream are doing more upstream work on the code than the original maintainer, their version should be made to work as an updated version of the original code so that everyone else can benefit. That is the free software way - share your modifications to benefit others. Embedded code is not just a security problem, it is also an insult to the community. It is saying "we've improved foo but if you want to use our free software improvements to foo with bar, you have to do all the integration work yourself because we can't be bothered or have been unable to work with the foo maintainer properly so we keep our changes to ourselves instead." (Says he after many, many arguments within GnuCash over several years about using libqof1 instead of embedding libgncqof as a private library. I'm the upstream and Debian maintainer of libqof* but after very ugly threads within GnuCash over a prolonged period of time, I decided to continue the work from outside. I haven't given up yet but it is *so* much harder when both packages already exist in Debian yet have no common development goals. Sometimes you do have to accept a fork but even then, the upstream package should produce a public library from that fork, not keep their version private. Sadly, GnuCash still does not do this.) > so it'd be > better at all if I'd set a dependency on it and don't ship the code > again, right? YES. This is particularly relevant for PHP because the security team are already trying to remove embedded code (where one package embeds a version of another package) and there are quite enough problems with PHP security as it is without adding more. Shipping it in the upstream source is acceptable if it is clearly and completely disabled and there is some evidence that the maintainer is actively persuading upstream to drop the unwanted code. > First of all my question is how to do that. Can I just create a symlink > to the other package or must I modify the upstream source to look at the > right place (without using links)? 1. Talk to upstream, ask them about preparing separate source tarballs. (Be prepared to fight hard but be nice, at least initially.) 2. During the build, ensure that options that may exist to disable the relevant components actually work. File bugs upstream for those that fail. 3. If the embedded code is retained in the upstream tarball, put in debian/copyright that the embedded code is disabled in Debian and point to the relevant packages. 4. Patch the upstream source to do TheRightThing(tm) and send the patches upstream in whatever passes for a BTS upstream. Set a high priority and keep pinging the reports until someone sees sense. > And the next question is: what can I do if upstream uses a modified > version of that lib? Isolate the relevant person in upstream and mercilessly harass him into seeing sense. Repeat until upstream dies, complies or you give up the package entirely. (Remember, upstream cannot remove you as Debian maintainer of the package without finding another DD to either be maintainer or sponsor and going through the same process with someone else - quite possibly someone else not as polite and patient as you. Debian decides who maintains a package and how that package is required to operate within Debian, not upstream. Debian Policy is designed to improve Debian packages and forward those improvements into the upstream package for everyone to share - not go cap-in-hand to upstream as a servant or minion.) > Is there a proper way to ship just the > modifications and for the rest use the files of the lib package? A wrapper. A new piece of code that acts as a secondary interface between the real interface (in the dependency package) and the forked interface (in the upstream source). A wrapper is a high-maintenance solution - *YOU* will have to maintain it, test it and develop it. *YOU* are responsible for the bugs caused by the wrapper. Explain this in copious detail to the relevant person upstream and drown him in complaints (and bugs) until upstream give in and make the package work with the dependency and remove the embedded code. Whatever arguments are put forward by upstream, they are all predetermined to be false and void - make your case and stick to it come what may. Don't just complain and become a troll - do the work, show them how it *should* work and give them usable patches so that they have no excuse. If the package never actually gets into Debian that is arguably *better* than letting bad code into Debian that has to be removed at some point down the line. (As above, fixing this *after* the upload is a thousand times harder - especially if both packages have been part of a stable release in Debian.) (Notice how none of these options allow for the package to continue as-is - that is deliberate because that is not a valid option for Debian or any sane operating system. Debian has quite enough problems of this nature with packages already in Debian (e.g. gnucash/qof and the ongoing saga over embedded copies of various mpeg code), there is no excuse for adding more when so much work is involved in getting rid of the ones we have.) You may quote any part of this email to upstream but you may want to rephrase it and use quotes selectively, depending on how upstream react to initial requests. (Omit the references to QOF or GnuCash.) Start off helpful, pleasant and tactful. Provide working solutions for the problems that you raise (i.e. do the work *FIRST* and go to upstream with a working solution). Avoid any stigma of "just complaining" by always providing an answer as well as the problem and then being prepared to work with upstream to integrate that solution without ever compromising on the final goal. Help them see sense but ensure that your ultimate objective is unambiguous and non-negotiable (which it is). Most upstream teams will accept your help (I work successfully with multiple upstream teams) but if you come across one that refuses to come to their collective senses (as I did), it is better to forget that package and do something else than to commit yourself to a permanent and distasteful dissonance that only makes life harder for yourself and upstream. Been there, done that, don't recommend it. Think carefully about these issues *before* you spend too much time on such packages. There are good reasons why some issues have big red flags. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part