[ITP] p7zip

Charles Wilson cygwin@cwilson.fastmail.fm
Sun Jun 17 19:16:00 GMT 2007


Dave Korn wrote:
> On 17 June 2007 06:22, Charles Wilson wrote:
> 
>> 7-Zip is a file archiver with a high compression ratio in its native
>> compression mode (LZMA).  
> 
>> http://cygutils.fruitbat.org/ITP/p7zip-4.47-1.tar.bz2
> 
>   Packaging's a bit bizarre.
> 
> 1.  Executables in a package-specific subdir of /usr/lib, wrapper scripts in
> /usr/bin.  Odd but not actually incorrect.

That's the way p7zip works, when you have built either 7z.exe or 
7zCon.sfx.  7z.exe dlopens 7z.so to obtain unpack-only support of a 
number of additional compression formats, and dlopens 
/usr/lib/p7zip/*/*.so for support of specific individual codecs (like 
'Rar.so', not provided here).

[if you build only 7za.exe and/or 7zr.exe, then they will go directly in 
$bindir, as expected]

These '.so' files are actually DLLs but they are never directly linked, 
only dlopened -- so they don't need to be named *.dll.  I suspect the 
application code dlopen's using exe_path + "/7z.so" or exe_path + 
"Codec/DIR/FN.so".  We don't want /usr/bin/Codec/*, so...

7zCon.sfx is the stub executable for building self-extracting archives; 
7z.exe and 7za.exe expect it to be in the same directory as themselves, 
and again, you probably don't want to clutter $bindir with non-executables.

The downside is you can't create a windows shortcut to /usr/bin/7z?.exe 
-- but that usage doesn't really make sense for these commandline apps: 
how would you specify the files to archive?

If you want a windows shortcut, you probably want the native, GUI, 
version of 7-Zip anyway.

> 2.  Empty 'Codecs' subdir of /usr/lib/p7zip present in source build, missing
> from binary package.  Dunno if this matters.

Hmm. Yes, I should probably use cygport's .keepdir feature.  Thx.

> 3.  All the docs under /usr/share/doc/p7zip-4.47 don't exist, they are just
> symlinks to originals in the not-necessarily-installed source package, e.g:
> 
> lrwxrwxrwx cwilson/None       0 2007-06-17 05:58
> usr/share/doc/p7zip-4.47/DOCS/7zC.txt ->
> /usr/src/p7zip/p7zip-4.47-1/src/p7zip_4.47/DOCS/7zC.txt
> 
>   This is clearly not going to work for most people!

Urk.  Sorry 'bout that.


>> http://cygutils.fruitbat.org/ITP/p7zip-4.47-1-src.tar.bz2
> 
>   The cygport install stage warns:
> 
> *** Warning: Cygwin README is missing
> 
> and the package stage warns:
> 
> *** Warning: setup.hint is missing

Well, that's just...wrong.  I don't get that error.  I wonder if I 
shipped the wrong .cygwin.patch.  Does 
p7zip-4.47-1/src/p7zip_4.47/CYGWIN-PATCHES contain anything at all?

>   Also, the install stage generates and the package stage packages /two/ docs
> directories, /usr/share/doc/p7zip/ and /usr/share/doc/p7zip-4.47/, which
> doesn't match the binary package you supplied, which only has the latter
> directory, containing all the contents of both.

Oh, I know why this happened:

src_install_fini_hook() {
         cd ${D}
         mv usr/share/doc/${PN}/* usr/share/doc/${PN}-${PV}/
         rmdir usr/share/doc/${PN}
}

but Yaakov still -- after six months -- has not integrated my _hook 
patch for cygport, so this function never gets called.  The perfect is 
the enemy of the good, in that situation.

I can either

(1) make a note in the README with a link to the cygport patch
http://cygwin.com/ml/cygwin/2006-12/msg00626.html

(2) patch the p7zip-supplied install.sh script to use 
/usr/share/doc/${PN}-${PV} directly.

The latter case is harder for me, because I have to update my patch 
every time ${PV} changes.  The former case is harder for everyone else, 
because they have to build and install a custom cygport.

Sigh.  I guess I can do #2 since to fix the symlink issue above I have 
to do major surgery...

>> http://cygutils.fruitbat.org/ITP/p7zip.hint
> 
>   Looks good.
> 
>   +1 when the above warts get resolved.

Thanks...

--
Chuck



More information about the Cygwin-apps mailing list