[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: packaging questions

> There are two issues in packaging software from this site that
> aren't dealt with well in the documentation.  Although well tested,
> the code is not well organized and in working on a logical
> structure for creating libraries, it is necessary to take files
> from a number of locations. In one case, slatec, there are
> about 3 or 4 packages that would be created from the source.
> To further complicate matters, files are often duplicated (or
> have slightly different versions) in more than one place.
> Also, some of the source is only available as a shell archive.
> As you can see, it is a bit of a mess and makes me want
> to totally ignore Debian policy and simply make packages as
> if they are original Debian packages, i.e. no .diff files.
> What do others think about this?

As an Idealist, I'd say, create a .orig.tar.gz, and .diff.gz,
send an email to the original site explaining why all the work
you've done in collection the best/most recent versions of all
of them files was ReallyGood, and hope they will use your
.orig.tar.gz as new "upstream" source. (to do that, you'd have
to have an .orirg.tar.gz that doens't do anything "debian", but
only does everything the netlib people should have done, but didn't
have time to do. They should be very happy with you!).

Even if they don't take over your work, it may be best to have a
"madeup" .orig.tar.gz: that way, when you really have to make changes,
you can easily distinguish between the original .c files and your

> The second issue has to do with shared and static libraries.
> Since this code is primarily used by people doing research,
> everyone will be compiling their own executables.
> Also, most people would either want to use static libs to
> get that tiny bit of extra speed or couldn't be bothered
> learning how to create executables linked against shared libs
> (if this sounds crazy to you then you've never been to graduate
> school in engineering).
> What do people think of the idea of creating a package with only
> static libraries, i.e. a library package without a -dev version and
> no shared libs? Another issue in favor of this is the size
> of the libraries, e.g. the shared library for lapack is almost
> 3M in size. Only having one version of the library will save
> a lot of space.

Well, in principle I don't think you've got as good a case to go
against the debian rules here as you had with the .orig.tar.gz.
And, the debian rules are quite clear: every package that provides
libs, should have an accompanying -dev package that includes the
static libs.
However, I've got at least one package (fakeroot) where this general
rule is absolutely useless (an executable with a statically linked in
fakeroot lib will not even run at all!). And, in general I'd say
that this rule should only be apply when it makes sence: in the fakeroot
example, it clearly doesn't make sence (actualy, i'd like to have the
rules changed to inlcude something like this).
I'm not sure whether having static libs is ever really needed
(though I do agree that having shared libs is essential: as
others noted, this may greately reduce the memory requrements of
the system), but the policy says they should be included. So,
I'd say you have no really good case here to be rebellious.

BTW, I don't know what netlib all does, but it sounds really interesting.
   if you're packaging this, I'll probably start using it too.

joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: