Difference between revisions of "Talk:DeveloperWiki:Building in a Clean Chroot"

From ArchWiki
Jump to: navigation, search
m (Building in the Chroot: there are several grammatically correct ways to say this; l like "in" for the preposition.)
 
(36 intermediate revisions by 9 users not shown)
Line 1: Line 1:
Should it not be mandated, that every TU and Dev have to do this? I mean, almost every day i see some new dependency issue or library error on flyspray.
+
==mkarchroot reads from local pacman.conf==
 +
I just ran the mkarchroot without providing any custom confs and yet it started syncing the repos I have in my local pacman.conf. Is there anything I am missing? --[[User:Maevius|Maevius]] ([[User talk:Maevius|talk]]) 08:57, 6 December 2012 (UTC)
  
Wait, this doesn't fix that issue unless the program is also launched in a chroot? Then that also should be mandated? any other ideas?
+
:Can you still reproduce this? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:35, 19 July 2018 (UTC)
 +
 
 +
==<s>--root is deprecated</s>==
 +
Under "Setting Up A Chroot" under the "Classic Way" section, one of the things it tells you to do is
 +
 
 +
# mkarchroot $CHROOT/root base-devel
 +
 
 +
Upon running the command, though it worked, I receive the message
 +
 
 +
# warning: option --root is deprecated; use --sysroot instead
 +
 
 +
So, this page needs to be updated.
 +
 
 +
[[User:Morningpee|Morningpee]] ([[User talk:Morningpee|talk]]) 02:24, 19 July 2018 (UTC)
 +
 
 +
:https://bugs.archlinux.org/task/58778 -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:34, 19 July 2018 (UTC)
 +
 
 +
== Improve language of sections for installing packages in the chroot ==
 +
 
 +
I really think these two sections are overly vague about what they do and why. We don't have to hold anybody's hand, but we could be a bit more descriptive. In particular, we need to settle on terms to describe and distinguish the "underlying" chroot from the "overlay" chroot.
 +
 
 +
===Current:===
 +
==== Building in the Chroot ====
 +
 
 +
Firstly, make sure the base chroot is up to date with:
 +
 
 +
# arch-nspawn $CHROOT/root pacman -Syu
 +
 
 +
Then, to build a package in the working chroot (by default, {{ic|$CHROOT/$USER}}), run the following from the dir containing the PKGBUILD:
 +
 
 +
$ makechrootpkg -c -r $CHROOT
 +
 
 +
Passing the {{ic|-c}} flag to {{ic|makechrootpkg}} ensures that the working chroot is cleaned before building starts.
 +
 
 +
==== Manual package installation ====
 +
{{Comment|The title should communicate that packages will be installed in the working chroot.}}
 +
Packages can be installed manually to the working chroot by using:
 +
 
 +
# makechrootpkg -r $CHROOT -I package-1.0-1-x86_64.pkg.tar.xz
 +
 
 +
If done from a directory that contains a PKGBUILD, the package will then be built. Avoid being in such a directory if you want to just install the package.
 +
 
 +
==== Installation after building ====
 +
{{Comment|The title should communicate that packages will be installed in the working chroot.}}
 +
Tell makechrootpkg to simply install a package to the working chroot after building by passing the -i arg. Unrecognized args get passed to makepkg, so this calls `makepkg` with the -i arg.
 +
{{Comment|This statement about passing arguments to makepkg would better fit in a subsection of "Building in the chroot" about "Passing arguments to makepkg"}}
 +
 
 +
# makechrootpkg -r $CHROOT -- -i
 +
 
 +
===Proposal:===
 +
==== Building in the Chroot ====
 +
 
 +
Firstly, make sure the base chroot ({{ic|$CHROOT/root}}) is up to date:
 +
 
 +
# arch-nspawn $CHROOT/root pacman -Syu
 +
 
 +
Then, to build a package in the working chroot ({{ic|$CHROOT/$USER}}), run the following in the directory containing its [[PKGBUILD]]:
 +
 
 +
$ makechrootpkg -c -r $CHROOT
 +
 
 +
Passing the {{ic|-c}} flag to {{ic|makechrootpkg}} ensures that the working chroot is cleaned before building.
 +
 
 +
===== Passing arguments to makepkg =====
 +
To pass arguments to [[Makepkg#Usage|{{ic|makepkg}}]], pass them after an end-of-options marker; e.g., to force a check():
 +
 
 +
$ makechrootpkg -c -r $CHROOT -- --check
 +
 
 +
==== Install packages into the working chroot ====
 +
Packages can be installed to the chroot by passing {{ic|-I}} to {{ic|makechrootpkg}}:
 +
 
 +
$ makechrootpkg -r $CHROOT -I package-1.0-1-x86_64.pkg.tar.xz
 +
 
 +
If the working directory contains a PKGBUILD, the package will be rebuilt after installation.
 +
 
 +
:That's untrue. Your proposal differentiates the {{ic|-I $pkgfile}} argument to makechrootpkg, from {{ic|-- -i}} forwarding {{ic|-i}} to makepkg itself, based on whether it affects the base {{ic|$CHROOT/root}} chroot vs. the {{ic|$CHROOT/<copy>}} chroot used for building.
 +
:But, it is self-evident (from the examples here, if not from the {{ic|makechrootpkg --help}} text which just mentions "install a package" and leaves that unclear if it refers to {{ic|pacman -U pkgfile.pkg.tar.xz}} or {{ic|pacman -S pkgname}}) that one installs a built package file, and one tells makepkg to build a package and then install the result.
 +
:And in fact, they both install to the working copy, since the "root" copy should never, ever, ever have things installed to it -- its whole purpose for existing is to be a completely pristine image with only the bare minimum specification for a build chroot, used for regenerating working copies. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:11, 12 October 2018 (UTC)
 +
 
 +
::Then perhaps you begin to see how the previous language was hard to understand; I had been operating in the understanding that this is precisely what was meant when the {{ic|makechrootpkg -r $CHROOT -I}} method described installing to the "working chroot" and the {{ic|makechrootpkg -r $CHROOT -- -i}} described installing to a "rw layer". To be honest I didn't do things this way, but this is how I interpreted what was written on this page.
 +
::This being the case, I think we should do away with one or the other altogether. No sense recommending two different ways to do the same thing, and given that the first method is prone to allowing packages built in unclean environments to be installed in the clean chroot, I think we should keep the second method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:23, 12 October 2018 (UTC)
 +
 
 +
:::Then the language here may be even more confusing than you still think.... The {{ic|-I}} flag exists for very valid reasons, specifically if you're building in a clean chroot you don't want litter from the previous makechrootpkg run -- so you'll tend to be using {{ic|-c}} to clean it, plus {{ic|-I}} to install a previously built makedepends of a new package rather than leaving the recursive makedepends of every package you're rebuilding.
 +
:::IMO should get rid of the mention of {{ic|-- -i}}, because we assume users know why they're manually installing packages to the chroot rather than obtaining them from the sync repos. Whereas I have no idea why anyone wants to install packages to the chroot when there isn't a PKGBUILD in the directory either, nor do I understand why one would wish to install the package afterwards using {{ic|-- -i}} except as a matter of slight laziness when rebuilding a stack of packages.
 +
:::Also I've got no clue what a rw layer is, so I fixed the description there... -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:53, 12 October 2018 (UTC)
 +
 
 +
::::I don't think anyone knew what "rw layer" was; thank you for taking care of that. As for which keeping the other install method, fine by me. If we're going to have a subsection about passing arguments to makepkg, an interested party could figure out from there about {{ic|-i}}. Proposal updated accordingly.[[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:03, 12 October 2018 (UTC)

Latest revision as of 16:55, 12 October 2018

mkarchroot reads from local pacman.conf

I just ran the mkarchroot without providing any custom confs and yet it started syncing the repos I have in my local pacman.conf. Is there anything I am missing? --Maevius (talk) 08:57, 6 December 2012 (UTC)

Can you still reproduce this? -- Alad (talk) 13:35, 19 July 2018 (UTC)

--root is deprecated

Under "Setting Up A Chroot" under the "Classic Way" section, one of the things it tells you to do is

# mkarchroot $CHROOT/root base-devel

Upon running the command, though it worked, I receive the message

# warning: option --root is deprecated; use --sysroot instead

So, this page needs to be updated.

Morningpee (talk) 02:24, 19 July 2018 (UTC)

https://bugs.archlinux.org/task/58778 -- Alad (talk) 13:34, 19 July 2018 (UTC)

Improve language of sections for installing packages in the chroot

I really think these two sections are overly vague about what they do and why. We don't have to hold anybody's hand, but we could be a bit more descriptive. In particular, we need to settle on terms to describe and distinguish the "underlying" chroot from the "overlay" chroot.

Current:

Building in the Chroot

Firstly, make sure the base chroot is up to date with:

# arch-nspawn $CHROOT/root pacman -Syu

Then, to build a package in the working chroot (by default, $CHROOT/$USER), run the following from the dir containing the PKGBUILD:

$ makechrootpkg -c -r $CHROOT

Passing the -c flag to makechrootpkg ensures that the working chroot is cleaned before building starts.

Manual package installation

Comment: The title should communicate that packages will be installed in the working chroot.

Packages can be installed manually to the working chroot by using:

# makechrootpkg -r $CHROOT -I package-1.0-1-x86_64.pkg.tar.xz

If done from a directory that contains a PKGBUILD, the package will then be built. Avoid being in such a directory if you want to just install the package.

Installation after building

Comment: The title should communicate that packages will be installed in the working chroot.

Tell makechrootpkg to simply install a package to the working chroot after building by passing the -i arg. Unrecognized args get passed to makepkg, so this calls `makepkg` with the -i arg.

Comment: This statement about passing arguments to makepkg would better fit in a subsection of "Building in the chroot" about "Passing arguments to makepkg"
# makechrootpkg -r $CHROOT -- -i

Proposal:

Building in the Chroot

Firstly, make sure the base chroot ($CHROOT/root) is up to date:

# arch-nspawn $CHROOT/root pacman -Syu

Then, to build a package in the working chroot ($CHROOT/$USER), run the following in the directory containing its PKGBUILD:

$ makechrootpkg -c -r $CHROOT

Passing the -c flag to makechrootpkg ensures that the working chroot is cleaned before building.

Passing arguments to makepkg

To pass arguments to makepkg, pass them after an end-of-options marker; e.g., to force a check():

$ makechrootpkg -c -r $CHROOT -- --check

Install packages into the working chroot

Packages can be installed to the chroot by passing -I to makechrootpkg:

$ makechrootpkg -r $CHROOT -I package-1.0-1-x86_64.pkg.tar.xz

If the working directory contains a PKGBUILD, the package will be rebuilt after installation.

That's untrue. Your proposal differentiates the -I $pkgfile argument to makechrootpkg, from -- -i forwarding -i to makepkg itself, based on whether it affects the base $CHROOT/root chroot vs. the $CHROOT/<copy> chroot used for building.
But, it is self-evident (from the examples here, if not from the makechrootpkg --help text which just mentions "install a package" and leaves that unclear if it refers to pacman -U pkgfile.pkg.tar.xz or pacman -S pkgname) that one installs a built package file, and one tells makepkg to build a package and then install the result.
And in fact, they both install to the working copy, since the "root" copy should never, ever, ever have things installed to it -- its whole purpose for existing is to be a completely pristine image with only the bare minimum specification for a build chroot, used for regenerating working copies. -- Eschwartz (talk) 15:11, 12 October 2018 (UTC)
Then perhaps you begin to see how the previous language was hard to understand; I had been operating in the understanding that this is precisely what was meant when the makechrootpkg -r $CHROOT -I method described installing to the "working chroot" and the makechrootpkg -r $CHROOT -- -i described installing to a "rw layer". To be honest I didn't do things this way, but this is how I interpreted what was written on this page.
This being the case, I think we should do away with one or the other altogether. No sense recommending two different ways to do the same thing, and given that the first method is prone to allowing packages built in unclean environments to be installed in the clean chroot, I think we should keep the second method. quequotion (talk) 15:23, 12 October 2018 (UTC)
Then the language here may be even more confusing than you still think.... The -I flag exists for very valid reasons, specifically if you're building in a clean chroot you don't want litter from the previous makechrootpkg run -- so you'll tend to be using -c to clean it, plus -I to install a previously built makedepends of a new package rather than leaving the recursive makedepends of every package you're rebuilding.
IMO should get rid of the mention of -- -i, because we assume users know why they're manually installing packages to the chroot rather than obtaining them from the sync repos. Whereas I have no idea why anyone wants to install packages to the chroot when there isn't a PKGBUILD in the directory either, nor do I understand why one would wish to install the package afterwards using -- -i except as a matter of slight laziness when rebuilding a stack of packages.
Also I've got no clue what a rw layer is, so I fixed the description there... -- Eschwartz (talk) 15:53, 12 October 2018 (UTC)
I don't think anyone knew what "rw layer" was; thank you for taking care of that. As for which keeping the other install method, fine by me. If we're going to have a subsection about passing arguments to makepkg, an interested party could figure out from there about -i. Proposal updated accordingly.quequotion (talk) 16:03, 12 October 2018 (UTC)