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

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 --------------------------

    [ non-operational comments omitted, please see original ]

usage(){ [ nice help messages also omitted, please see original ] }

[ $# != 5 ] && usage ;
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
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 -----------------------
------------------- 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 -----------------------
------------------- 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.


Reply to: