Re: Packages
"KH" == Kai Henningsen <kai@khms.westfalen.de> writes:
----------------------- and I quote in full ---------------------------
KH> bhogan@rahul.net (Bill Hogan) wrote on 20.02.96 in <[🔎] m0toqwT-0003luC@bedlam.rahul.net>:
>> [remainder of shell script elided -- please see original]
>>
>> I did that and it gave me this:
KH> Umm ... why on earth do you include the script that everyone could have
KH> had from the shar archive?!
>> AFAICT, this script will accept any `.tar.gz' file whatsoever,
>> unpack it under $work, create the file $work/DEBIAN/control, and then
>> merely feed the entire $work directory tree to `dpkg-deb', resulting
>> in a `.deb' file structure that can be read by `dpkg'.
KH> Right. That means that the original archive must have its pathnames
KH> relative to the root directory for this to have any use. Slackware
KH> packages follow that convention, most .tar.gz probably won't.
KH> Anyway, from looking at this, it should be sort of obvious how it works.
KH> MfG Kai
------------------------------ end quote -------------------------------
Ok, thanks.
That's what I thought, only I wanted to make sure I had not made a
mistake when I executed the share script you posted.
But first, so the reader knows what I am talking about, here again
is the script I referred to above as "this script", slightly edited:
---------------------------- Exhibit A --------------------------
#!/bin/bash
[ non-operational comments omitted, please see original ]
usage(){ [ nice help messages also omitted, please see original ] }
[ $# != 5 ] && usage ;
work=/tmp/slack2deb.$$
mkdir $work
tar -x -C $work -z -f $1
mkdir $work/DEBIAN
cat >$work/DEBIAN/control <<EOF
Package: $2
Version: $3
Maintainer: $4
Description: $5
EOF
dpkg-deb -b $work
dpkg-name $work.deb
rm -rf $work
-------------------------- End exhibit A -----------------------
Next, for the benefit of those who have never looked inside a
Slackware package, here is a listing of what is inside the
Slackware-2.3 cpio.tgz package:
# tar ztf cpio.tgz
-------------------- Exhibit B -----------------------
./
usr/
usr/doc/
usr/doc/cpio-2.3/
usr/doc/cpio-2.3/NEWS
usr/doc/cpio-2.3/README
usr/man/
usr/man/preformat/
usr/man/preformat/cat1/
usr/man/preformat/cat1/cpio.1.gz
usr/man/preformat/cat1/mt.1.gz
bin/
bin/cpio
bin/mt-GNU
install/
install/doinst.sh
------------------- End exhibit B --------------------
So now suppose I do this:
# slack2deb cpio.tgz slack-cpio 0 gonzo@nowhere "slackware-2.3 cpio"
True enough, the output file I get (it has a funny name because I
had to comment out the call to `dpkg-name' in the script) can be read
by `dpkg':
# dpkg --info /tmp/slack2deb.454.deb
----------------------- Exhibit C ---------------------------
old debian package, version 0.939000.
size 28758 bytes: control archive= 215, main archive= 28530.
91 bytes, 4 lines control
Package: slack-cpio
Version: 0
Maintainer: gonzo@nowhere
Description: slackware-2.3 cpio
----------------------- End exhibit C -----------------------
And, true enough, after I have executed `dpkg --install' on this
`.deb' file, I can use `dpkg' to do such things as this:
# dpkg --listfiles slack-cpio
------------------------ Exhibit D -----------------------
/.
/usr
/usr/doc
/usr/doc/cpio-2.3
/usr/doc/cpio-2.3/NEWS
/usr/doc/cpio-2.3/README
/usr/man
/usr/man/preformat
/usr/man/preformat/cat1
/usr/man/preformat/cat1/cpio.1.gz
/usr/man/preformat/cat1/mt.1.gz
/bin
/bin/cpio
/bin/mt-GNU
/install
/install/doinst.sh
------------------- End exhibit D ----------------------
However, executing `dpkg --install' on this `.deb' file does not
cause the file `/install/doinst.sh' to be executed -- and a Slackware
package cannot be said to have been installed until after the
Slackware-standard `/install/doinst.sh' script for that package has
been executed.
For example, in the case of cpio.tgz, `/install/doinst.sh'
contains these two commands:
------------- Exhibit E ---------
( cd bin ; rm -rf mt )
( cd bin ; ln -sf mt-GNU mt )
----------- End exhibit E -------
As the output from `dpkg --listfiles' above shows, `mt-GNU' has
not been moved to `mt'; even this "simple" case is not so simple when
you think about it and in some of the other Slackware packages the
respective `/install/doinst.sh' scripts are much more complicated.
So, any time I execute `dpkg --install' on the pseudo-Debian
package that I get by executing `slack2deb' on a bona fide Slackware
package, I still have to choose between two alternatives, neither of
which I find particularly appealing:
(a) if I do not execute `/install/doinst.sh' then I will not
complete the installation process but I will necessarily be taking a
large risk of clobbering my Debian setup in the process nonetheless;
(b) if I do execute `/install/doinst.sh' then I may complete the
installation process but I will necessarily be taking a large risk of
clobbering my Debian setup even more in the process.
By contrast, when I execute `dpkg --install' on a bona fide Debian
package, I have a reasonable basis for expecting to find its contents
completely integrated with my existing Debian system and I am not
necessarily taking a large risk of clobbering my setup in the process.
Thus, whatever else might be said about it, `slack2deb' does not
convert a bona fide Slackware package into a bona fide Debian package.
Beyond that I must say I think the idea handing out fake Debian
passports for the purpose of smuggling non-Debian software across the
Debian border is one of the worst ideas I have come across in a long
time; all it achieves it to once again open the door to the very kinds
of problems which the Debian `dpkg' package management system was
designed to keep out.
BH
Reply to: