Installing packages to a foreign system

[Phillip Susi]

I'm trying to debootstrap a system and when I chroot into it to install
more packages, many fail because their configure scripts assume they are
being called from a running system and try to interact with it and
modify the running state, instead of just the filesystem.  For example,
daemon packages try to start the daemon in the configure script, which
you can't do running inside a chroot.  So my question is, what is the
proper way to install packages into a foreign system's filesystem such
that they do not attempt to modify the running host system?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Phillip Susi <psusi@...> writes:

> I'm trying to debootstrap a system and when I chroot into it to
> install more packages, many fail because their configure scripts
> assume they are being called from a running system and try to interact
> with it and modify the running state, instead of just the filesystem.
> For example, daemon packages try to start the daemon in the configure
> script, which you can't do running inside a chroot.  So my question
> is, what is the proper way to install packages into a foreign system's
> filesystem such that they do not attempt to modify the running host
> system?

man invoke-rc.d
less /usr/share/doc/sysv-rc/README.policy-rc.d.gz

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Phillip Susi]

This looks like it does the trick, but I am curious; is this how the
installer does it?  When the installer is first installing the system it
also needs to install the packages to the hard disk, but without having
them interfere with the running state of the installing system.  Is this
how it does that?

On 9/23/2009 5:12 AM, Goswin von Brederlow wrote:

> Phillip Susi<psusi@...>  writes:
>
>> I'm trying to debootstrap a system and when I chroot into it to
>> install more packages, many fail because their configure scripts
>> assume they are being called from a running system and try to interact
>> with it and modify the running state, instead of just the filesystem.
>> For example, daemon packages try to start the daemon in the configure
>> script, which you can't do running inside a chroot.  So my question
>> is, what is the proper way to install packages into a foreign system's
>> filesystem such that they do not attempt to modify the running host
>> system?
>
> man invoke-rc.d
> less /usr/share/doc/sysv-rc/README.policy-rc.d.gz
>
> MfG
>          Goswin
>
>

--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Phillip Susi <psusi@...> writes:

> This looks like it does the trick, but I am curious; is this how the
> installer does it?  When the installer is first installing the system
> it also needs to install the packages to the hard disk, but without
> having them interfere with the running state of the installing system.
> Is this how it does that?
>
> On 9/23/2009 5:12 AM, Goswin von Brederlow wrote:
>> Phillip Susi<psusi@...>  writes:
>>
>>> I'm trying to debootstrap a system and when I chroot into it to
>>> install more packages, many fail because their configure scripts
>>> assume they are being called from a running system and try to interact
>>> with it and modify the running state, instead of just the filesystem.
>>> For example, daemon packages try to start the daemon in the configure
>>> script, which you can't do running inside a chroot.  So my question
>>> is, what is the proper way to install packages into a foreign system's
>>> filesystem such that they do not attempt to modify the running host
>>> system?
>>
>> man invoke-rc.d
>> less /usr/share/doc/sysv-rc/README.policy-rc.d.gz
>>
>> MfG
>>          Goswin
>>
>>

It is what policy dictates for every package. Would be stupid to
invent something else.

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Phillip Susi]

On 9/28/2009 7:06 AM, Goswin von Brederlow wrote:
> Phillip Susi<psusi@...>  writes:
>
>> This looks like it does the trick, but I am curious; is this how the
>> installer does it?  When the installer is first installing the system
>> it also needs to install the packages to the hard disk, but without
>> having them interfere with the running state of the installing system.
>> Is this how it does that?
> It is what policy dictates for every package. Would be stupid to
> invent something else.

So is a package broken if its configure script invokes tools that rely
on a running daemon, and the configure fails if the tools can't contact
the daemon?  Like say, udevinfo?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Phillip Susi <psusi@...> writes:

> On 9/28/2009 7:06 AM, Goswin von Brederlow wrote:
>> Phillip Susi<psusi@...>  writes:
>>
>>> This looks like it does the trick, but I am curious; is this how the
>>> installer does it?  When the installer is first installing the system
>>> it also needs to install the packages to the hard disk, but without
>>> having them interfere with the running state of the installing system.
>>> Is this how it does that?
>> It is what policy dictates for every package. Would be stupid to
>> invent something else.
>
> So is a package broken if its configure script invokes tools that rely
> on a running daemon, and the configure fails if the tools can't
> contact the daemon?  Like say, udevinfo?

Verry problematic.

It gets even worse. What if it contacts the daemon runing outside the
chroot and gets totaly the wrong information?

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Phillip Susi]

On 10/5/2009 5:08 AM, Goswin von Brederlow wrote:
>> So is a package broken if its configure script invokes tools that rely
>> on a running daemon, and the configure fails if the tools can't
>> contact the daemon?  Like say, udevinfo?
>
> Verry problematic.
>
> It gets even worse. What if it contacts the daemon runing outside the
> chroot and gets totaly the wrong information?

Exactly, so how do you make sure this does not happen?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Phillip Susi <psusi@...> writes:

> On 10/5/2009 5:08 AM, Goswin von Brederlow wrote:
>>> So is a package broken if its configure script invokes tools that rely
>>> on a running daemon, and the configure fails if the tools can't
>>> contact the daemon?  Like say, udevinfo?
>>
>> Verry problematic.
>>
>> It gets even worse. What if it contacts the daemon runing outside the
>> chroot and gets totaly the wrong information?
>
> Exactly, so how do you make sure this does not happen?

I use xen or kvm. With a chroot you can never be sure some maintainer
doesn't do something like this.

But if you do see something of this kind I would report it as bug.

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Phillip Susi]

On 10/7/2009 12:42 AM, Goswin von Brederlow wrote:
> I use xen or kvm. With a chroot you can never be sure some maintainer
> doesn't do something like this.
>
> But if you do see something of this kind I would report it as bug.

Well, you can be sure it won't happen if you don't bind mount /sys,
/proc, and /dev into the chroot.  But I guess that answers my question
then; if a package fails to install because there is no /sys, /proc, and
/dev, then it is broken and should be bug reported.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Goswin von Brederlow-2]

Phillip Susi <psusi@...> writes:

> On 10/7/2009 12:42 AM, Goswin von Brederlow wrote:
>> I use xen or kvm. With a chroot you can never be sure some maintainer
>> doesn't do something like this.
>>
>> But if you do see something of this kind I would report it as bug.
>
> Well, you can be sure it won't happen if you don't bind mount /sys,
> /proc, and /dev into the chroot.  But I guess that answers my question
> then; if a package fails to install because there is no /sys, /proc,
> and /dev, then it is broken and should be bug reported.

Nah, you can need those.

MfG
        Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

Hello,

On Thu, 08 Oct 2009, Goswin von Brederlow wrote:

> Phillip Susi <psusi@...> writes:
>
> > On 10/7/2009 12:42 AM, Goswin von Brederlow wrote:
> >> I use xen or kvm. With a chroot you can never be sure some maintainer
> >> doesn't do something like this.
> >>
> >> But if you do see something of this kind I would report it as bug.
> >
> > Well, you can be sure it won't happen if you don't bind mount /sys,
> > /proc, and /dev into the chroot.  But I guess that answers my question
> > then; if a package fails to install because there is no /sys, /proc,
> > and /dev, then it is broken and should be bug reported.
>
> Nah, you can need those.

Can you please stop this discussion here and continue it in a more
appropriate place ?

This has nothing to do with the development of dpkg.

Cheers,
--
Raphaël Hertzog


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Phillip Susi]

On 10/8/2009 2:25 AM, Raphael Hertzog wrote:
> Can you please stop this discussion here and continue it in a more
> appropriate place ?
>
> This has nothing to do with the development of dpkg.

It has everything to do with dpkg.  dpkg is used to install packages,
and the discussion is about installing packages not to the currently
running system.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Phillip Susi]

On 10/7/2009 7:44 PM, Goswin von Brederlow wrote:
>> Well, you can be sure it won't happen if you don't bind mount /sys,
>> /proc, and /dev into the chroot.  But I guess that answers my question
>> then; if a package fails to install because there is no /sys, /proc,
>> and /dev, then it is broken and should be bug reported.
>
> Nah, you can need those.

If the package requires them to install, then it will not work when you
are trying to install to a foreign system since if it is not running, it
has no /proc, /dev, and /sys, and any one that is provided would belong
to the installing system, not the system being installed to, so the
package would end up manipulating the wrong system.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Mon, 26 Oct 2009, Phillip Susi wrote:
> On 10/8/2009 2:25 AM, Raphael Hertzog wrote:
> >Can you please stop this discussion here and continue it in a more
> >appropriate place ?
> >
> >This has nothing to do with the development of dpkg.
>
> It has everything to do with dpkg.  dpkg is used to install
> packages, and the discussion is about installing packages not to the
> currently running system.

dpkg is used to install all packages, it doesn't mean this list is
appropriate to discuss any generic issue with package installation, please
continue this on -devel. You will have more feedback and I will not be
disappointed because the new message in -dpkg is not relevant for me as
dpkg developer.

Cheers,
--
Raphaël Hertzog


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...