Re: Installing from scratch with debs

[Petr Čech]

On Sun, Mar 11, 2001 at 04:59:53PM -0600 , Gordon Sadler wrote:
> I'm not 100% clear why Debian has Priority: required ... and
> Essential: yes, seems there is probably a historical reason. It would
> probably be less confusing/complex to use just one to designate both.

no. Essential: yes is there so you don't have to depend on them. And it's
twice as hard to remove them
Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

 thats \\GNU\Linux$ to you


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installing from scratch with debs

[Brian May]

> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes:

Colin> "Zack Weinberg" <[EMAIL PROTECTED]> wrote:
>> Installing debs onto a bare system proved to be harder than I'd
>> thought.  Obviously you start with the Essential packages.

Colin> Isn't unpacking base2_2.tgz the easiest way to start, or
Colin> has this been obsoleted now? I agree it's less elegant.

I have been told that it will be obsolete when unstable is
released. See Bug#89079.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installing from scratch with debs

[Anthony Towns]

On Sun, Mar 11, 2001 at 11:14:51AM -0800, Zack Weinberg wrote:
> I ran this script for all the Essential packages and the transitive
> closure of their dependencies.  In case you're curious, these are all
> the packages which are not Essential but included in the transitive
> closure:
>  libc6
>  libcap1
>  libdb2
>  libncurses5
>  libpam-modules
>  libpam-runtime
>  libpam0g
>  libreadline4
>  libstdc++2.10-glibc2.2
>  mawk

lib* packages aren't allowed to be essential (see policy) since that
would make it impossible for us to move to new versions (libc5 -> libc6).

mawk isn't essential since it uses alternatives and gawk works just as
well if you want to swap them.

More interesting is the set of packages in required that aren't in the
transitive closure of essential. Probably they shouldn't be there...

> Packages providing daemons tend to start them in their postinst.
> That's fine in most cases, but not when you're installing into a
> chroot tree and the same daemon is already running outside.  They try
> to bind their TCP socket(s), fail, and die.  Fortunately most
> postinsts don't consider this a fatal error.

boot-floppies and debootstrap link start-stop-daemon to /bin/true to
stop this from happening.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)

 PGP signature

Re: Installing from scratch with debs

[Gordon Sadler]

On Sun, Mar 11, 2001 at 11:14:51AM -0800, Zack Weinberg wrote:

> 
> I ran this script for all the Essential packages and the transitive
> closure of their dependencies.  In case you're curious, these are all
> the packages which are not Essential but included in the transitive
> closure:
> 
>  libc6
>  libcap1
>  libdb2
>  libncurses5
>  libpam-modules
>  libpam-runtime
>  libpam0g
>  libreadline4
>  libstdc++2.10-glibc2.2
>  mawk
> 
> I'm not sure why base-files wants awk.
>
Not trying to degrade any of your information here. The above packages
are all listed as required however.

Debian-policy 2.2 (ver 3.5.2.0)

required
  required packages are necessary for the proper functioning of
  the system. You must not remove these packages or
  your system may become totally broken and you may
  not even be able to use dpkg to put things back.
  Systems with only the required packages are probably
  unusable, but they do have enough functionality to allow the sysadmin
  to boot and install more software.
  
I'm not 100% clear why Debian has Priority: required ... and
Essential: yes, seems there is probably a historical reason. It would
probably be less confusing/complex to use just one to designate both.
KISS principle and all.

Gordon Sadler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installing from scratch with debs

[Colin Watson]

"Zack Weinberg" <[EMAIL PROTECTED]> wrote:
>Installing debs onto a bare system proved to be harder than I'd
>thought.  Obviously you start with the Essential packages.

Isn't unpacking base2_2.tgz the easiest way to start, or has this been
obsoleted now? I agree it's less elegant.

>I ran this script for all the Essential packages and the transitive
>closure of their dependencies.  In case you're curious, these are all
>the packages which are not Essential but included in the transitive
>closure:
>
> libc6
> libcap1
> libdb2
> libncurses5
> libpam-modules
> libpam-runtime
> libpam0g
> libreadline4
> libstdc++2.10-glibc2.2

These would all be included in the admonition in policy about shared
libraries and the essential flag, presumably.

>Packages providing daemons tend to start them in their postinst.
>That's fine in most cases, but not when you're installing into a
>chroot tree and the same daemon is already running outside.  They try
>to bind their TCP socket(s), fail, and die.  Fortunately most
>postinsts don't consider this a fatal error.

I believe that Henrique Holschuh is working on this as part of his
invoke-rc.d proposal; have a look back through the archives of -devel
and -policy.

-- 
Colin Watson [[EMAIL PROTECTED]]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installing from scratch with debs

[Zack Weinberg]

On Sun, Mar 11, 2001 at 11:32:27AM -0800, David Whedon wrote:
> Have you looked at the package 'debootstrap'?  It does much of what you are
> looking for. Perhaps you can look at that and coordinate with Anthony Towns so
> you two aren't doing duplicate work.

No I haven't, thanks.  (But I have already finished the installation
and I don't plan on doing it again soon.)

> > 1. dpkg won't do anything at all if /var/lib/dpkg doesn't exist and
> >doesn't contain two files (status, available) and two directories
> >(info, updates).  They can all be empty, but you have to create
> >them by hand.  I don't see why dpkg doesn't create these if they
> >don't exist.
> I agree that this would be nice.  Perhaps file a wishlist bug against dpkg?

bug #89327.

> > base-config has serious bugs at present.  Passwords are echoed to the
> > screen, and it does some ridiculous grep loop over the password file
> > which takes about five minutes to complete.  With no indication of
> > what's happening.  I thought it had wedged.  Finally, it gets
> > seriously confused when it hits the bit about running tasksel or
> > dselect, and errors out.  I wound up setting up shadow MD5 passwords
> > and accounts by hand - this is not hard.
> ick, have bugs been filed?

bugs #89324 and #89325, echoing passwords and hanging for two minutes,
respectively.  I don't remember enough details about what happened
when it tried to run tasksel to file a coherent bug report.

zw


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installing from scratch with debs

[David Whedon]

Have you looked at the package 'debootstrap'?  It does much of what you are
looking for. Perhaps you can look at that and coordinate with Anthony Towns so
you two aren't doing duplicate work.

> 1. dpkg won't do anything at all if /var/lib/dpkg doesn't exist and
>doesn't contain two files (status, available) and two directories
>(info, updates).  They can all be empty, but you have to create
>them by hand.  I don't see why dpkg doesn't create these if they
>don't exist.
I agree that this would be nice.  Perhaps file a wishlist bug against dpkg?

> 
> 5. makedev is not Essential, and not much depends on it, but it's the
>only package which will create /dev - if you leave it out, you get
>no /dev, and all kinds of things mysteriously break.  This is
>easily worked around by doing (cd /mnt/dev && MAKEDEV generic) by
>hand, first, if you remember.
FYI, debootstrap handles this by creating devices.tar.gz. 

> 
>  (To find out what Status: line
> corresponded to 'iU' in dpkg -l, I had to dig through the apt
> sources.  Why is the status file format undocumented?)

I can't imagine the lack of documentation is by design.
 
> 
> I ran this script for all the Essential packages and the transitive
> closure of their dependencies.  In case you're curious, these are all
> the packages which are not Essential but included in the transitive
> closure:
> 
>  libc6
>  libcap1
>  libdb2
>  libncurses5
>  libpam-modules
>  libpam-runtime
>  libpam0g
>  libreadline4
>  libstdc++2.10-glibc2.2
>  mawk
interesting.

> 
> 
> base-config has serious bugs at present.  Passwords are echoed to the
> screen, and it does some ridiculous grep loop over the password file
> which takes about five minutes to complete.  With no indication of
> what's happening.  I thought it had wedged.  Finally, it gets
> seriously confused when it hits the bit about running tasksel or
> dselect, and errors out.  I wound up setting up shadow MD5 passwords
> and accounts by hand - this is not hard.
ick, have bugs been filed?

> 
> I understand that installer generation has to jump through some of the
> same hoops, so I hope my experience provides some useful insights.
> I've attached the unpacking script.
>
cool, thanks,

David



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Installing from scratch with debs

[Zack Weinberg]

I recently got a new hard drive and wanted to reinstall Debian on it.
The machine tracks unstable, so I figured it would be easier just to
download all the relevant .debs and dpkg -i them into the target file
system, than make boot floppies for Potato and then re-upgrade.

Installing debs onto a bare system proved to be harder than I'd
thought.  Obviously you start with the Essential packages.  But the
moment you try 'dpkg --root=/mnt --install libc6_2.2.1-1_i386.deb' you
discover five or so serious problems:

1. dpkg won't do anything at all if /var/lib/dpkg doesn't exist and
   doesn't contain two files (status, available) and two directories
   (info, updates).  They can all be empty, but you have to create
   them by hand.  I don't see why dpkg doesn't create these if they
   don't exist.

2. Preinst scripts won't run chrooted into a bare file system; there's
   nothing to run them with.  I tried dpkg-deb -x'ing enough packages
   that a minimal preinst could run - bash, libc6, fileutils - only to
   hit the next problem:

3. All the Essential packages have incomplete dependency lists.  This
   isn't surprising; their dep lists are intended to make upgrades of
   complete systems work.  Their true dep lists are much longer, and
   contain lots of cycles.  You rapidly get into a tangle where A
   won't unpack because it pre-depends on B, but B won't configure
   because its postinst expects A to be present.  They also have a
   fair number of dependencies on packages which are not Essential,
   and you have to get those too.

4. dpkg-deb -x doesn't update the status file or extract the control
   files, which means dpkg has no idea that certain packages should be
   hit by -a --configure.

5. makedev is not Essential, and not much depends on it, but it's the
   only package which will create /dev - if you leave it out, you get
   no /dev, and all kinds of things mysteriously break.  This is
   easily worked around by doing (cd /mnt/dev && MAKEDEV generic) by
   hand, first, if you remember.

I solved all these problems by writing a shell script that would
extract a .deb into a specified directory, ignoring all dependency
fields, and not running preinst scripts.  (It appears that none of the
Essential preinsts need to do anything when installing from scratch
with a modern dpkg.)  Then it would extract the control files,
generate a .list file, and fake a status file entry, leaving the
package in the 'unpacked' state.  (To find out what Status: line
corresponded to 'iU' in dpkg -l, I had to dig through the apt
sources.  Why is the status file format undocumented?)

I ran this script for all the Essential packages and the transitive
closure of their dependencies.  In case you're curious, these are all
the packages which are not Essential but included in the transitive
closure:

 libc6
 libcap1
 libdb2
 libncurses5
 libpam-modules
 libpam-runtime
 libpam0g
 libreadline4
 libstdc++2.10-glibc2.2
 mawk

I'm not sure why base-files wants awk.

Once this had been done, 'dpkg -a --configure' succeeded, leaving me
with a minimal but functional installation.  Then I downloaded all the
other packages I want, and did 'dpkg -iGE *.deb' to install them.  I
believe this would have worked in principle.  dpkg presently has a
bug, which causes it to segfault after unpacking five to ten packages.
I think this is the same bug that is being discussed right now on
debian-dpkg.  I also think it has something to do with the length of
the command line.  Note that -iGE will skip over hundreds of packages
without a problem; the crash only happens after it starts unpacking
things.

You can't just repeat the command, because the packages that it
unpacked have not yet been configured, and for some reason dpkg will
try to unpack them again instead of just configuring them and moving
on.  It will therefore crash again, in the same place.
dpkg -a --configure doesn't necessarily work, either, because it may
not have gotten to all the dependencies of the unpacked packages.  You
have to find those and install them individually, then configure
pending packages, then try to install *.deb again.  Repeat ad
nauseam.  After about an hour of this I got everything installed.

I couldn't use apt to do this, because for some mysterious reason,
even if you provide apt with a complete set of Packages and Release
files, pkgcache.bin, and all the debs in /var/cache/apt/archives, and
say --no-download, it still tries to do DNS lookups.  These fail
because there's no /etc/resolv.conf yet (in my configuration, that
gets created by the DHCP client - which is running outside the chroot,
but apt inside doesn't know that.)

Packages providing daemons tend to start them in their postinst.
That's fine in most cases, but not when you're installing into a
chroot tree and the same daemon is already running outside.  They try
to bind their TCP socket(s), fail, and die.  Fortunately most
postinsts don't consider this a fatal error.

base-config has serious bugs at pr