On Wed, Oct 03, 2007 at 12:57:06AM -0700, Russ Allbery wrote: > Nikolaus Schulz <microschulz@web.de> writes: > > Wouldn't merging the packages require some patch management system? I > > hoped to get along without such a thing. > > It would require that you make modifications to the upstream source, > probably. So will lots of other things, though. The only packages for > which I don't end up needing some sort of patch management system or > strategy for modifying the upstream source are ones for which I'm > upstream. Sorry, it's clear that I have to modify the source, and I have already done so. With "patch management system" I meant something like dpatch. Doesn't dumping several upstream tarballs in one Debian source package require something like that? > > How big? Byte-wise they're small, my current GPL deb's are <100k each. > > The binary library packages eat 700k for one printer series. > > It sounds like between that and the separate binaries for different > printing systems, it would be useful to separate things out into separate > packages. Yes, something like two or three packages for each printer series might be reasonable. In principle, I think it is desirable to * keep pure CUPS packages separate, * keep core drivers and GUI clients seperate, * keep programs separate that depend on the non-free libraries. I still have to check what can be reasonably done here. But the GUI program which pops up the printing dialog shares two binary libraries with the core driver, so it's clear I can't split this if I have to make these libs private to one package. :-( > I personally am not particularly uncomfortable with shipping binary > packages that use RPATH to find libraries in a subdirectory of /usr/lib, > provided that they have a tight dependency on exactly the version of the > library package they need (which for this application you'll probably need > anyway). Other people may differ. I agree. So making the libraries private would be a possible way to do it, sidestepping the shlibs problem... Given the annoying dependencies of the GUI client, is there any doable alternative? If there is no hard showstopper, I would still find it more natural to have the libs as a separate package. One could argue that certainly no other free software will link against such undisclosed libraries, but why shouldn't there exist more than one (non-free or contrib) package using them? Do the strict assumptions of the shlibs format really make it impossible to package libraries with unversioned sonames? > > Hmm, I guess I should mention another problem. Unfortunately one of > > these binary libraries has a path hard-coded: it expects private data > > files in /usr/lib/bjlib. I'm not sure, is this fatal? What is the best > > course of action here? > > What sort of private data files? At least at first glance, that doesn't > seem unreasonable, as long as it doesn't expect to do something like write > to the at path. Configuration files and undocumented binary data, probably describing internals of the supported printers. They seem to be read-only. I was just worrying about the directory name, because it might not comply with policy; especially since "bjlib" probably won't be the package name. > This pile of code does sound like a rather spectacular mess, though, so > it's worth thinking long and hard about whether Debian really needs it. It is an awful mess, yes! And I've asked myself more than once if it's a sane idea to package this. But these drivers support printer models and model specific features for which, to my knowledge, no free alternative exists. And my impression is that many Debian and Ubuntu users already use these drivers anyway; either by "alienizing" the official Canon rpm's, or by installing the unofficial Debian packages at [1]. And even the latter don't even try to meet Debian standards. So I think, yes, there are many Debian users who need it; and I want to package it. Clearly this won't be a very nice package, but it will be an ugly package or no package at all. I just hope the thing will finally be good enough to both find a sponsor and have the ftp-masters wave it. Nikolaus [1] http://mambo.kuhp.kyoto-u.ac.jp/~takushi/#canon
Attachment:
signature.asc
Description: Digital signature