Re: Multipart package (IRAF)
On Wed, 18 Feb 1998, Zed Pobre wrote:
NOTE: this is all IMO, not policy.
> -----BEGIN PGP SIGNED MESSAGE-----
>
> I've finally found a piece of software that I think might be useful to
> Debian (it would actually be a major selling point to people in the
> astronomy, physics and astrophysics fields) that I might actually be
> able to maintain without upgrading to hamm, but I have a few questions
> before I offer to wrap it up:
>
> The software package comes in three primary source files, one of which
> is general, and the other two of which contain the statically linked
> binaries. Source is sort of provided for the entire thing, but not in
> a format that uses conventional Makefiles.
my take on this is that here is something you can give back to the
upstream source - re-organise the source so that it *can* build easily
on any system. portability like that may be just what the program needs
to get more people involved in it's development and maintainence.
> In short, I have a package where the source *is* in fact provided, but
> is effectively inseparable from the binaries, and the binaries are
> huge. I don't want to recompile the entire mess for two reasons: 1) I
> don't know enough about IRAF to make sure that I won't break something
> even if I get it to compile, 2) I'd have to do it once for libc5 and
> then again for libc6 on va and I *know* I won't be able to fix any
> bugs I made coming in off of two different systems. My original
> thought was to create the three "base" files and a master file that
> contained just the scripts required to set up the system. My next
> option was to run the entire thing into one package, but it'll have a
> mother of a transmission time as the installed size is 150 megs.
Are these binaries program files or data files?
if some or all of these binaries are data files then split them off as a
package called '<PACKAGE>-data'.
If you can break up the data files into meaningful sub-sets then try to do
so. e.g. <PACKAGE>-data-min, <PACKAGE>-data-optional like the gimp package
has done. or use more meaningful names if you can, e.g.
<PACKAGE>-data-stars, <PACKAGE>-data-planets, etc.
set Depends, Recommends (if you must), and Suggests control fields as
appropriate.
if the binary data also has source files which are used to generate the
data files then that should be packaged separately, along with the tools
used to generate the data.
if some/all of the binaries are programs then you should compile them.
As manoj said, this isn't strictly required by policy (imo it should
be)...but it seems to me that if you can't compile the package then you
probably shouldn't be maintaining it. sorry, that's just the way i see
it.
it sounds like you might have picked a tough package as your first
one... you may want to try to team up with another debian developer who
also has a strong interest in these fields (if possible, of course).
also IMO, new packages should be compiled for libc6 now.
> If I make it four packages, three of those packages are going to have
> as source packages a lot of files, and no code to compile. One of
> those packages is going to contain a lot of source code, some of which
> is internally necessary for the program to automagically create some
> of the things it creates, most of which is source for the program
> itself, and no way to distinguish between the two.
where you can, you should break up the package into user level stuff and
development stuff. if you can, you should re-organise the code into
logically separate groupings, and split them off into separate packages.
even better, make them create and use their own shared libraries if
appropriate.
yes, this is a LOT of work. you've picked a tough package. however, if you
pull it off then the upstream user & development community will be very
grateful for your organisational work (it sounds like they might need
it...i get the impression that the programs in question have grown over
the years into an unmanageable behemoth).
if you can get the re-org. task started and looking like it is going
somewhere, you may find that you generate enough interest and enthusiasm
from the upstream authors that they will finish the job - this is good,
they know the code like no-one else can :)
the upstream developers would probably LOVE to have their code become more
managable, and get to the point where it is easily compiled on any unix
system. they'd also probably love to have their software easily
installable by new users using .deb packages. they might see debian as a
nearly "turnkey" environment for their software...and also an environment
which supports stuff like pvm and other parallel computing libs which
could be extremely useful for these applications. anyone working in these
fields probably has a very strong interest in beowulf class linux
clusters....$50,000 on a comparatively "slow" supercomputer is a lot
easier on the budget than $1,000,000+ on a fast one.
> What does Policy dictate that I do with something like this?
i don't think policy really covers this. i'm just going by what i feel
is the Right Thing to do. Of course, I'm not the one doing the work so
i can afford to make all these grand suggestions :-)
> Also, is it preferable for me to make three base packages based
> entirely upon the stuff I downloaded from the NOAO IRAF site, and one
> package that is created from scratch to finish up the install that
> depends upon the other three, or is it preferable to write the install
> scripts into one of the three base files and make it depend upon the
> other two?
i just reread your message and it seems like the second two "source
archives" only contain statically linked binaries. in that case, the
decision is simple: throw them away and recompile from source. The
comments i made about splitting up the package into logically separate
groupings still aplies.
you may find that once you start splitting it up into smaller, more
manageable pieces that the job isn't anywhere near as hard as it looked
when it was a monolithic monster.
> And as a last question, the following copyright *looks* like it meets
> the standard for "free", but I thought I'd post it to see if anyone
> else sees something suspicious:
[ license snipped ]
that license seems perfectly fine to me. can't see anything in it that
conflicts with the DFSG.
craig
--
craig sanders
--
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: