[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Connecting those interested in getting GT.M into the Debianrepositories



Dear Bhaskar,

here are two short comments about unpacking binary packages and dependance on
libicu.


Le Mon, Sep 06, 2010 at 11:40:55PM -0400, K.S. Bhaskar a écrit :
> 
> Preference for no root owned files in the .deb distribution files: I have a
> preference for not including any files owned by root in the .deb distribution
> files.  This makes it easy for anyone who wants to analyze a package to be able
> to unpack it without needing root access.

Debian binary packages are archives in GNU ‘ar’ format, that contain two
compressed tar archives, control.tar.gz and data.tar.gz. Installed files are in
control.tar.gz and although they are owned by root, tar will substitute the
ownership for the local user, so there is no need to have a root access to
inspect the contents of a Debian package. In summary, you can just type ‘ar -x
packagename.deb’ and then ‘tar xfz control.tar.gz’ to unpack a package in the
current directory. (In rare cases, the control and data tar archives may be
compressed with a different program, like bzip2, but the principle stays the
same.)


> Unicode version: GT.M itself requires ICU version 3.6 or higher.  However,
> there is a defect in the way Debian packages ICU, by putting the version number
> in the package name (e.g., libicu36).  So, there is no way to define a
> dependency for GT.M of version 3.6 or greater.  Also, there is a very useful
> program icu-config that is part of libicu-dev rather than libicu.

Currently, the lowest version of ICU in Debian is 3.8, so there is no immediate
problem with the naming scheme anyway. Furthermore, the dependancy on packages
like libicu36 are machine-inserted at build time. As you noted, the development
package itself does not have a version number encoded in its name. Therefore,
the GT.M source package can build-depend on libicu-dev ( >= w.x ), where w.x is
what GT.M needs, and the binary package will automatically depend on a libicuyz
package determined from the analysis of the symbols used by the GT.M binary
packages, and a file contained in libicu-dev listing in which version of the
library they were introduced.


Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


Reply to: