On Wed, Mar 28, 2007 at 04:54:52PM +0200, Romain Beauxis wrote: > However, I see you have made significant changes to the makefile system, in > order to create a shared object with the correct name and to link dynamically > the utilities to the shared library, great ! These are not significant changes, they are trivial changes. A significant change would be autotoolising the system. > But, I would advise to put this as patch, and not let it stay into the > diff.gz. There are several reasons for that: > * Upgrading the package to new upstream release will be much more easy, and if > the patch fails you'll see where etc.. > * Any other user/DD may then see precisly what changes you are doing to > upstream sources. You will also be able to seperate the changes that perform > a different task. Currently, any other user can see what I'm doing by looking at the .diff.gz. Under dpatch, they would have to notice in the .diff.gz that I'm using dpatch, then look at both the double-diffed dpatch and the 00list file, or _apply_ the .diff.gz and then look at the diff in debian/patches I don't consider the above that onerous, but others have expressed the opinion that it is so, and so I prefer to not require it when trivial. > * You may submit the final patch upstream.. I suspect they don't want it. I doubt they've accidentally produced staticly-built utilities, a stripped shared library, and a shared object named as they have. > In your precise case, I would strongly suggest sumbiting this to upstream > since it corrects two facts that are very important (shared object name) and > important (linking utilities to shared objects). Neither of these are global truths or neccessary outside Debian. The shared object name is invisible to the system, ldconfig builds the correct symlinks irrespective of the name. And static binaries are much easier to run from the build directory without installing the whole package. Which is handy if you don't care about libopenjpeg, but need something to convert to or from JP2 files. Interestingly, libblah-soversion.so appears to be how libtool creates private libraries, and it looks like libtool 1.4 may have done that with public libraries too. I probably will suggest to them that they rename the default .so file generated, but that'll be part of the same forum post that explains the risks and perils of soversion mistakes like the 1.1 to 1.1.1 update. > If only upstream would be using any suitable configure tool :) autotools would almost certainly be too large for this project. Maybe if they also rearranged the distribution to build everything together cohesively, there would be some advantage to it. But for just the library, written in what appears to be nice standrd C++ without any other libraries needed, it's overkill. > Then it is also a good training for a new packager to add patch support to > debian/rules. I don't think it will be very difficult for you.. *cough* Uh, I'm not a new packager, nor am I new to dpatch in particular. As I mentioned before, dpatch is my preferred patching infrastructure. That doesn't mean I feel it should be applied to every upstream tarball. I could accomplish the same thing with a little bit of effort in the debian/rules file, but that would produce the (accurate, and more relevant I feel) criticism that the build system used by 'make' is markedly different from that used by 'debian/rules binary' > Sorry to ask for many corrections, but I feel important that this package, and > others, have a good shape before upload.. I welcome and appreciate the feedback. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Attachment:
pgpl4IkvQaIps.pgp
Description: PGP signature