Bug#343513: please remove unneeded shared objects
On Thu, Dec 15, 2005 at 09:36:37PM +0100, Mohammed Adn?ne Trojette wrote: Please could you remove shared objects to handle non-7z formats from /usr/lib/p7zip/Formats ? All except 7z.so are only needed to compress or uncompress non-7z formats, but we already have utilities in Debian to deal with them. I've read the logs on #debian-devel about it, and I think it is a good idea. But on the other hand, 7za is exactly that: a standalone *.7z file extractor and compressor. If I had to make a p7zip udeb, I think I would do that (either strip all so files or only keep /usr/bin/7za). Yes, that'd make sense. But for a normal package rather than udeb. I think this is just taking unnecessary space. p7zip is very good with its own compression format, but it just doesn't make any sense to reimplement other format handler (and it doesn't use the external libraries where available either). p7zip packages, as of now, are a good way not to have to install all of arj, zip, ... utils to extract an archive file (that is the situation on my own laptop ;). Does my answer seems sane to you? Well, besides the problem that it is re-implementing code that is already in debian (and in a very mature stage), like zlib or libbz2, that's a valid point. However, I think most users really don't want it. I would suggest splitting the 7z binary and extra .so into a separate package so that people who just want to handle *.7z files get only what they need. If this doesn't convince you, maybe it's a good idea to ask for a third (fourth?) opinion in debian-devel ? Feel free to. Thanks! -- Robert Millan it's about trust... i don't trust them. that's all i need to know. (wrt Digital Restriction Management, seen in Slashdot) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343513: please remove unneeded shared objects
Package: p7zip Version: 4.30.dfsg-1 Severity: wishlist Hi! Please could you remove shared objects to handle non-7z formats from /usr/lib/p7zip/Formats ? All except 7z.so are only needed to compress or uncompress non-7z formats, but we already have utilities in Debian to deal with them. I think this is just taking unnecessary space. p7zip is very good with its own compression format, but it just doesn't make any sense to reimplement other format handler (and it doesn't use the external libraries where available either). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages p7zip depends on: ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libstdc++64.0.2-5The GNU Standard C++ Library v3 p7zip recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343513: please remove unneeded shared objects
On Thu, Dec 15, 2005, Robert Millan wrote: Hi! Hi Robert! Please could you remove shared objects to handle non-7z formats from /usr/lib/p7zip/Formats ? All except 7z.so are only needed to compress or uncompress non-7z formats, but we already have utilities in Debian to deal with them. I've read the logs on #debian-devel about it, and I think it is a good idea. But on the other hand, 7za is exactly that: a standalone *.7z file extractor and compressor. If I had to make a p7zip udeb, I think I would do that (either strip all so files or only keep /usr/bin/7za). I think this is just taking unnecessary space. p7zip is very good with its own compression format, but it just doesn't make any sense to reimplement other format handler (and it doesn't use the external libraries where available either). p7zip packages, as of now, are a good way not to have to install all of arj, zip, ... utils to extract an archive file (that is the situation on my own laptop ;). Does my answer seems sane to you? -- adn Mohammed Adnène Trojette
