Ben Gertzfield <[EMAIL PROTECTED]> writes: > John> I'd like feedback on it. I have opted to package it as it > John> is done upstream; that is, all the programs in one thing. > > Okay, here's a bit of feedback. :) > > prc-tools includes almost all of its files in /usr/m68k-palmos-coff/, > except two: > > gilgamesh:/home/che# dpkg --contents prc-tools_0.5.0-2_i386.deb > > *snip* > > -rw-r--r-- root/root 142336 1998-06-16 13:54 usr/lib/libreadline.a > -rw-r--r-- root/root 20270 1998-06-16 13:54 usr/lib/libmmalloc.a
This I've already fixed. There is now an -2 or -3 or so release of prc-tools in Incoming. These are not actually for the Pilot; these were built by gdb for i386, I believe, and AFAIK they are not necessary for anything except building gdb. My debian/rules has to delete a lot of stuff like that from the stuff to be installed and I happened to miss those two. > This makes it impossible to install prc-tools if you have > libreadlineg2-dev or any other package that has libmmalloc.a included > (not sure what this is offhand). Yeah. I went through about 5 compiles of -1 before I thought I had it cleared up. And I still missed those two :-) (At 30-40 mins per compile [100+ meg source tree], that took awhile) > These two should be moved into /usr/m68k-palmos-coff/. Actually, they're deleted :-) > This is a hard one; I think the point of a source package is to > have *everything* you need to build the target. If you have to > download other things, it becomes difficult quickly. This is a good point. Also I don't want 100+ meg of files cluttering up my cvs tree. > I'm not sure what the right solution is. I think I know what it is now. I want to make as few modifications as possible to the upstream. What it likes to do is untar binutils, gcc, and gdb; modify them; compile them; and then install them. If I were to include the modified gcc and gdb stuff (so that building the package only requires compiling and installing), upgrades would be a pain, and I worry about the ethics of including modified sources in the orig. Therefore, I believe that I will just dump the tar.gz's of binutils, gcc, and gdb into the toplevel of the package's tar file (or maybe the debian/ directory, I dunno), and then all I have to do is change the path that it looks for them from .. to . I have to use the very specific version that the prc-tools is contains patches for; others won't work. So there isn't really any good way to share code with the native gcc packages -- the native ones usually stay a few versions ahead. John -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | ----------------------------------------------------------------------------+ Visit the Air Capitol Linux Users Group on the web at http://www.aclug.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
