On Mon, Mar 17, 2003 at 06:36:23PM +0100, Christian Perle wrote: > So each time a single component of the knoppix-util package is updated, > you have to update the whole package? Unnecessary complicated. yes, but i don't see why it's complicated. for the end-user, upgrades are just as easy, for the maintainer, it's just as easy to upgrade a single large package once it's set up (usually you just put in the new source, write an entry into the changelog, and run dpkg-buildpackage). also, this way it takes up less space on the mirrors and Packages.gz files (the files that have lists of the 10000+ packages available for debian). > Klaus is very good in solving things the KISS way (keep it simple and > stupid). I am not very fond of the idea to "fuck up" everything just to > get it Debian compatible. well, i may be so bold as to say you don't understand what we're doing. personally, i will not be happy if the debian versions are any less capable than the packages that already exist. however, there are some serious issues that will keep some of the packages out (like the init), and we're doing our best to see if there isn't some other way to solve these problems. to repeat, if we can do this as we intend, there will be no noticable change to anyone using the stuff. also, just because we import it into debian doesn't mean that klaus will want to use our versions of his stuff, he may decide he likes his way better. > > > also, i think some of the packages may be able to be replaced by actual > > > debian-proper packages. for example ash could be replaced by dash (or > > > some other static-linked shell), right? > > Definitely. > > Is dash compatible with the shell scripts used in Knoppix at boot time? it seems to be with the exception of the mount command. we're looking into possible workarounds/solutions, but we may have to keep the patched ash for the time being. > > RFP could someone check and issue an RFP bug if this makes sense for general use > > BTS Packages which might be necessary to enhance in Debian to fit Knoppix needs > > Sorry for being clueless, but what is RFP and BTS? debian terms :) ITP: intent to package (saying "i'm going to package this") RFP: request for packaging (like ITP but asking someone else to do it) BTS: bug tracking system. one of debian's great features. > > p lintian: 1E, 1W > > p linda: 1E > > Lintian, linda, huh? Please explain. they're two programs that developers use to find problems (policy violations) with packages. anything we import into debian must have these problems resolved. debian policy is another strong point of the distro, quite possibly its strongest wrt to other linux distros > > K just a single script... > > ...which is totally sufficient for setting the console keyboard. yes, but i don't think that makes it merit its own package. there's a lot of overhead space used per-package, plus what i mentioned about the Packages.gz files, it would waste lots of peoples' bandwidth to keep it outside of knoppix-utils (or knoppix-utils-common, since it's a shell script) package. > > kdelock-knoppix 0.5 GPL > > http://www.knopper.net/knoppix/sources/ > > + knoppix native > > p just a single wrapper sh script (not bothering to build) > > K just a single script > > Read /usr/bin/kdesktop_lock, /cdrom/KNOPPIX/README_Security.txt and > find out why this package is important. (hint: passwords are disabled > in Knoppix) i'll take a look at it... > > knoppix-hdinstall 0.37-1 GPL > > http://www.itm.tu-clausthal.de/~perle/ > > URL is: > http://www.itm.tu-clausthal.de/~perle/knx/ yeah, fabian franz pointed that out and it's already been updated. the file can be found at: http://cs.swarthmore.edu/~finney/debian/knoppix_packaging.txt > > + knoppix native > > p wierd, has tarfiles of its own files inside it > > K could Christian Perle please comment on this > > It doesn't have templates *in* the script. The templates are located in a > tarball under /usr/local/lib. The reason for knx-hdinstall not being > installed under /usr is that it is still experimental software. You > also won't find it in the menus. okay, then this is something that would also have to be changed for a debianized package, because debian policy dictates to not touch /usr/local, and leave it for the local admin. just to re-emphasize, this doesn't mean we're saying "you have to change the way your software works", we're saying that we're going to make a modified debian version that gets along with the way things are done in debian. if you like the changes, great, feel free to take them, of course. > > knoppix-terminalserver 0.5-9 GPL > > http://www.knopper.net/knoppix/ > > + knoppix native > > p lintian: 4E, 3W > > p linda: 3E > > ! I'm waiting for comments - might be a little bit nifty. I would love > > to see this as real Debian package which might some developer sponsor > > AFAIK this script is heavily based on Knoppix (like exporting the > cloop image), so it would cost some effort to run it on non-Knoppix > systems. okay, so it's going to need a good looking over then. i'll add some comments to the audit. thanks. > > loop-aes 1.6i GPL > > + ftbfs, wanted to modify some of my kernel source > > No, it does *not* modify the kernel source. The kernel source tree has > to be installed, though. The file loop.c is copied from the kernel > source tree to the build location of loop-aes, patched and compiled > there. The resulting loop.o is copied to /lib/modules/... > However, to make use of the loop-AES module, losetup and mount have to > be patched (those versions are included in the package). it may not be modifying a source file, but it's dying because it's trying to write a file into my kernel source tree: balthasar[~/debian/debian-knoppix/processed/loop-aes-1.6i]13:06:54$ fakeroot ./debian/rules binary <snip> make[2]: Entering directory `/usr/src/kernel-source-2.4.20' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c /usr/bin/ld: cannot open output file scripts/split-include: Permission denied collect2: ld returned 1 exit status make[2]: *** [scripts/split-include] Error 1 make[2]: Leaving directory `/usr/src/kernel-source-2.4.20' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/seanius/debian/debian-knoppix/processed/loop-aes-1.6i' make: *** [build-stamp] Error 2 i'm not sure if it really needs this stuff built or not, and haven't tried it on an already built source tree. i'll try that at some point. > > util-linux 2.11x ??? (has GPL and BSD licenses included, but doesn't specify) > > xxx > > p doesn't ship with a ./debian > > ! Could you please comment about the difference to Debian package and > > how it might be enhanced. I've hear there were some statically linked > > I think it is the loop-AES-patched version. (losetup and mount are > included in util-linux) aha, thanks for clarifying that. sean
Attachment:
pgpf1NgN_EVfk.pgp
Description: PGP signature