Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot - Debian

This is a discussion on Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot - Debian ; Otavio Salvador writes: > Neil Williams writes: > >> On Wed, 03 Oct 2007 14:41:10 -0300 >> Otavio Salvador wrote: >> >>> Neil Williams writes: >>> >>> > Is there a cleaner way of achieving the same result, maybe debootstrap ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

  1. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    Otavio Salvador writes:

    > Neil Williams writes:
    >
    >> On Wed, 03 Oct 2007 14:41:10 -0300
    >> Otavio Salvador wrote:
    >>
    >>> Neil Williams writes:
    >>>
    >>> > Is there a cleaner way of achieving the same result, maybe debootstrap
    >>> > could support / as a default and allow an override on the command line?
    >>>
    >>> Hello Neil,
    >>>
    >>> Yes, I think that a command line option might be the best way to
    >>> handle that.
    >>>
    >>> Can you prepare a patch for it?

    >>
    >> I wasn't sure what name to use for the command line option and I'm not
    >> sure about how the patch results in:

    >
    > Maybe: --second-stage-target looks clearer.


    Could you update the manpage? So we can commit it.

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



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

  2. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    On Sat, 06 Oct 2007 15:33:43 -0300
    Otavio Salvador wrote:

    > >>> Can you prepare a patch for it?
    > >>
    > >> I wasn't sure what name to use for the command line option and I'm not
    > >> sure about how the patch results in:

    > >
    > > Maybe: --second-stage-target looks clearer.

    >
    > Could you update the manpage? So we can commit it.


    Unfortunately not - debootstrap contains no source for the manpage and
    I cannot even begin to edit groff/whatever.

    --

    Neil Williams
    =============
    http://www.data-freedom.org/
    http://www.nosoftwarepatents.com/
    http://www.linux.codehelp.co.uk/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHB9umk7DVr6iX/QIRAndSAJ4jW3mWZ4vrgkrA7IDAu7CJy8gyTQCgjlA4
    sqPZpjMK9wjQc5HPi3zmiC8=
    =qzXJ
    -----END PGP SIGNATURE-----


  3. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    On Sat, 06 Oct 2007 15:33:43 -0300
    Otavio Salvador wrote:

    > >> I wasn't sure what name to use for the command line option and I'm not
    > >> sure about how the patch results in:

    > >
    > > Maybe: --second-stage-target looks clearer.

    >
    > Could you update the manpage? So we can commit it.


    Is the lack of a manpage update going to block the bug?

    How is the debootstrap manpage normally updated?

    I would normally use doclifter if this was a package that I was
    maintaining - storing the XML in the package source and using
    docbook-xsl to update it prior to building the package to prevent a
    build dependency. However, using doclifter means that the diff to the
    original manpage is quite large and is not limited to the new text, it
    can also change (for the better usually) the appearance of certain
    parts of the manpage (headers generally).

    Currently, emdebian-tools is going to have to distribute a modified
    version of debootstrap in /usr/share/emdebian-tools/ in order to
    support this functionality in our root filesystem creation scripts. I'd
    rather have support within debootstrap itself and then emdebian-tools
    can just depend on debootstrap (>= 1.0.4).

    emdebian-tools 0.4.1 is due for upload to Emdebian tonight but I would
    like to have this fixed before the next round of debconf translations
    require an upload to Debian (at least two weeks).

    --


    Neil Williams
    =============
    http://www.data-freedom.org/
    http://www.nosoftwarepatents.com/
    http://www.linux.codehelp.co.uk/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHFOa9iAEJSii8s+MRAvauAJ9B7te/2as37hLedWsn1IF8OAeB6QCfRrnD
    Tw90KAla76LAyH4YncGvjss=
    =BzfX
    -----END PGP SIGNATURE-----


  4. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    Neil Williams writes:

    > On Sat, 06 Oct 2007 15:33:43 -0300
    > Otavio Salvador wrote:
    >
    >> >> I wasn't sure what name to use for the command line option and I'm not
    >> >> sure about how the patch results in:
    >> >
    >> > Maybe: --second-stage-target looks clearer.

    >>
    >> Could you update the manpage? So we can commit it.

    >
    > Is the lack of a manpage update going to block the bug?


    I don't indent to commit it before someone does it or I find the time
    to do that myself. If we start to accept those changes without
    properly documenting them we'll end with a bunch of undocumented
    options and personally I think we all wouldn't like to see it
    happening ;-)

    > How is the debootstrap manpage normally updated?
    >
    > I would normally use doclifter if this was a package that I was
    > maintaining - storing the XML in the package source and using
    > docbook-xsl to update it prior to building the package to prevent a
    > build dependency. However, using doclifter means that the diff to the
    > original manpage is quite large and is not limited to the new text, it
    > can also change (for the better usually) the appearance of certain
    > parts of the manpage (headers generally).


    Personally I do not object for a more "readable" source format for
    manpage and I doubt someone else will do too so if you can provide the
    patch for it, I'd commit it without problem :-)

    > Currently, emdebian-tools is going to have to distribute a modified
    > version of debootstrap in /usr/share/emdebian-tools/ in order to
    > support this functionality in our root filesystem creation scripts. I'd
    > rather have support within debootstrap itself and then emdebian-tools
    > can just depend on debootstrap (>= 1.0.4).
    >
    > emdebian-tools 0.4.1 is due for upload to Emdebian tonight but I would
    > like to have this fixed before the next round of debconf translations
    > require an upload to Debian (at least two weeks).


    Right. Let's see if we can make it happen before your deadline.

    Please, try to provide the patch and I'll try to handle it as soon as
    possible.

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



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

  5. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    On Tue, 16 Oct 2007 14:36:04 -0200
    Otavio Salvador wrote:

    > >> Could you update the manpage? So we can commit it.

    > >
    > > Is the lack of a manpage update going to block the bug?

    >
    > I don't indent to commit it before someone does it or I find the time
    > to do that myself. If we start to accept those changes without
    > properly documenting them we'll end with a bunch of undocumented
    > options and personally I think we all wouldn't like to see it
    > happening ;-)


    Come to think of it, --second-stage isn't in the current debootstrap
    --help message at all, only the man page.

    > > I would normally use doclifter if this was a package that I was
    > > maintaining - storing the XML in the package source and using
    > > docbook-xsl to update it prior to building the package to prevent a
    > > build dependency. However, using doclifter means that the diff to the
    > > original manpage is quite large and is not limited to the new text, it
    > > can also change (for the better usually) the appearance of certain
    > > parts of the manpage (headers generally).

    >
    > Personally I do not object for a more "readable" source format for
    > manpage and I doubt someone else will do too so if you can provide the
    > patch for it, I'd commit it without problem :-)


    OK. I've done the doclifter thing and updated the XML, generated a new
    manpage and compared it with the old. I'm assuming you don't want the
    build-dependency on docbook-xsl so I've included a patch to create a
    README that documents how to use xsltproc to generate the manpage.
    (Note that the man page *diff* is larger than the entire XML file!)

    > Please, try to provide the patch and I'll try to handle it as soon as
    > possible.


    Four patches attached.

    debootstrap.diff - the actual change to close this bug.

    README.diff - create a small README that doesn't have to be packaged
    with the binaries, only included in the source.

    debootstrap.8.xml.diff - creates the XML, generated from doclifter and
    including changes to cover the new option related to this bug.

    debootstrap.8.diff - probably unnecessary but demonstrates the level of
    changes incurred through doclifter that made it impossible to submit
    those as a patch to the man page itself. You probably don't want to
    apply that.

    There shouldn't be any need to change the contents of debian/* as
    neither of the new files need to be part of the debootstrap
    installation, only the source.

    I'm not sure how you create the source for debootstrap - presumably
    some form of RCS-dependent foo-buildpackage. I'm assuming that any file
    present in RCS will be included in the debootstrap_1.0.4.tar.gz so that
    is where I would expect to find README and debootstrap.8.xml in case of
    future changes.

    Please review the manpage changes - I think it makes for a slightly
    better manpage due to the whitespace and bold improvements. YMMV.

    HTH.

    --


    Neil Williams
    =============
    http://www.data-freedom.org/
    http://www.nosoftwarepatents.com/
    http://www.linux.codehelp.co.uk/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHFPT7iAEJSii8s+MRAqSIAJ9qJN9tKJqxs6qqJRBLSm Y7k/wy0gCg8RJr
    qyiH1pFN/wK4mNAvr5OgjBs=
    =cpaV
    -----END PGP SIGNATURE-----


  6. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    Neil Williams wrote:
    > OK. I've done the doclifter thing and updated the XML, generated a new
    > manpage and compared it with the old. I'm assuming you don't want the
    > build-dependency on docbook-xsl so I've included a patch to create a
    > README that documents how to use xsltproc to generate the manpage.
    > (Note that the man page *diff* is larger than the entire XML file!)


    Please don't ship files in the source that can be generated at build time.
    Requiring a manual step is just adding complexity and asking for
    mistakes.

    Is there a reason why you've chosen to use a manpage generation tool
    if you don't think it's good for the package to build-depend on it? For
    that matter, why choose docbook-xsl instead of docbook2x-man?

    And finally, isn't just vi $manpage easier than all this?

    Index: debootstrap.8
    ================================================== =================
    --- debootstrap.8 (revision 49792)
    +++ debootstrap.8 (working copy)
    @@ -92,6 +92,10 @@
    Complete the bootstrapping process. Other arguments are generally not
    needed.
    .IP
    +.IP "\fB\-\-second\-stage\-tarball DIR\fP"
    +Run second stage in a subdirectory instead of root. (can be used to create
    +a foreign chroot) (requires --second-stage)
    +.IP
    .IP "\fB\-\-keep\-debootstrap\-dir\fP"
    Don't delete the /debootstrap directory in the target after completing the
    installation.
    --
    see shy jo

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHFQExd8HHehbQuO8RAuX8AKDAQmqGXcmZMrT+h5BSqy/6cDMjLwCfX7YH
    z4io6SSYHxnnhPrQFpCWg8g=
    =whzf
    -----END PGP SIGNATURE-----


  7. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    On Tue, 16 Oct 2007 14:21:37 -0400
    Joey Hess wrote:

    > Neil Williams wrote:
    > > OK. I've done the doclifter thing and updated the XML, generated a new
    > > manpage and compared it with the old. I'm assuming you don't want the
    > > build-dependency on docbook-xsl so I've included a patch to create a
    > > README that documents how to use xsltproc to generate the manpage.
    > > (Note that the man page *diff* is larger than the entire XML file!)

    >
    > Please don't ship files in the source that can be generated at build time.


    Normally, I'd agree. In this case, I feel it is up to the maintainer to
    decide whether to add a build dependency. Especially as it is my
    complete inability to edit groff that led to the use of XML in the first
    place.
    :-)

    > And finally, isn't just vi $manpage easier than all this?


    Umm, no. I cannot edit groff - it makes about as much sense to me as
    lisp or haskell. I stick to what I know, C, Perl, XML and autotools. I
    just can't see the point of learning groff, just as I'd never try to
    deal with bugs in python or C#.

    Plus, the use of doclifter and xsltproc (using a stylesheet from
    docbook-xsl) makes for a better looking manpage than I could ever hope
    to achieve with vi. YMMV.

    > Index: debootstrap.8
    > ================================================== =================
    > --- debootstrap.8 (revision 49792)
    > +++ debootstrap.8 (working copy)
    > @@ -92,6 +92,10 @@
    > Complete the bootstrapping process. Other arguments are generally not
    > needed.
    > .IP
    > +.IP "\fB\-\-second\-stage\-tarball DIR\fP"
    > +Run second stage in a subdirectory instead of root. (can be used to create
    > +a foreign chroot) (requires --second-stage)
    > +.IP
    > .IP "\fB\-\-keep\-debootstrap\-dir\fP"
    > Don't delete the /debootstrap directory in the target after completing the
    > installation.
    > --
    > see shy jo


    Sorry, Joey, I know you understand groff but I don't. I have no idea
    where to start with all those \f commands.

    All my manpages are built from XML using docbook-xsl as a
    build-depends. Normally, I wouldn't have touched the manpage for this
    bug but Otavio asked me to provide a patch and the XML process was
    acceptable to him because it could make it easier for him to update
    the manpage too, so that's what I have done.

    Otavio: It's up to you if you want to dump README.diff and implement
    that xsltproc rule in the build, adding docbook-xsl to build-depends in
    the process. It's relatively painless and the best way overall, IMHO.

    --


    Neil Williams
    =============
    http://www.data-freedom.org/
    http://www.nosoftwarepatents.com/
    http://www.linux.codehelp.co.uk/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHFQhniAEJSii8s+MRAo5iAKDXxUHi+ce1VecVSyduLy FYFnHrAwCcChXf
    +lfFWQkCOIzKOqR7nmqtkIg=
    =F9Nm
    -----END PGP SIGNATURE-----


  8. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    Joey Hess writes:

    > Neil Williams wrote:
    >> OK. I've done the doclifter thing and updated the XML, generated a new
    >> manpage and compared it with the old. I'm assuming you don't want the
    >> build-dependency on docbook-xsl so I've included a patch to create a
    >> README that documents how to use xsltproc to generate the manpage.
    >> (Note that the man page *diff* is larger than the entire XML file!)

    >
    > Please don't ship files in the source that can be generated at build time.
    > Requiring a manual step is just adding complexity and asking for
    > mistakes.
    >
    > Is there a reason why you've chosen to use a manpage generation tool
    > if you don't think it's good for the package to build-depend on it? For
    > that matter, why choose docbook-xsl instead of docbook2x-man?
    >
    > And finally, isn't just vi $manpage easier than all this?


    I've commited using your (Joey's) manpage version since the diff was
    much smaller.

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



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

  9. Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot

    Neil Williams writes:

    > Otavio: It's up to you if you want to dump README.diff and implement
    > that xsltproc rule in the build, adding docbook-xsl to build-depends in
    > the process. It's relatively painless and the best way overall, IMHO.


    Personally I like the idea to use a xml based manpage however I prefer
    to have one bug for it and then people comment about it
    specifically. For now, I've commited joeyh manpage change and your
    debootstrap change. So this bug has been set to pending ;-)

    Feel free to report a new bug with the manpage suggestion. I agree with
    this improvement for a later commit.

    --
    O T A V I O S A L V A D O R
    ---------------------------------------------
    E-mail: otavio@debian.org UIN: 5906116
    GNU/Linux User: 239058 GPG ID: 49A5F855
    Home Page: http://otavio.ossystems.com.br
    ---------------------------------------------
    "Microsoft sells you Windows ... Linux gives
    you the whole house."



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

+ Reply to Thread