[buildpkg] Add local packages to the chroot #98

Closed
opened 2015-05-27 06:44:04 +00:00 by philm · 6 comments
philm commented 2015-05-27 06:44:04 +00:00 (Migrated from gitlab2.manjaro.org)

Created by: Kirek

I want to add the option to add local packages to the chroot when building packages, but before starting I want to ask which way should we do it.

Basically this functions already exist with mkchrootpkg with the -I option, but buildpkg doesn't support it.
With devtools the extra arguments (options after --) that you pass with "unstable-x86_64-build" command are passed to the mkchrootpkg functions, but with buildpkg we pass them to makepkg.

So two options:

  • We pass the extra arguments to mkchrootpkg instead of makepkg
  • Add an extra option (-I for example) to buildpkg that will be passed to mkchrootpkg

So any thoughts which way we should go?

*Created by: Kirek* I want to add the option to add local packages to the chroot when building packages, but before starting I want to ask which way should we do it. Basically this functions already exist with mkchrootpkg with the -I option, but buildpkg doesn't support it. With devtools the extra arguments (options after --) that you pass with "unstable-x86_64-build" command are passed to the mkchrootpkg functions, but with buildpkg we pass them to makepkg. So two options: - We pass the extra arguments to mkchrootpkg instead of makepkg - Add an extra option (-I for example) to buildpkg that will be passed to mkchrootpkg So any thoughts which way we should go?
philm commented 2015-05-27 08:27:04 +00:00 (Migrated from gitlab2.manjaro.org)

Created by: udeved

buildpkg can install built package in the chroot with -n switch, which also runs a namcap check.
I think what you want is already there. :)

In mkchrootpkg:

 n) run_namcap=true; makepkg_args+=(-i) ;;

You mean you want to specify a path to a package you want to install in chroot, ie a pkg which is not (yet) in repo? I didn't see any usecase for -I, if you can install any built pkg in chroot.

*Created by: udeved* buildpkg can install built package in the chroot with -n switch, which also runs a namcap check. I think what you want is already there. :) In mkchrootpkg: ``` n) run_namcap=true; makepkg_args+=(-i) ;; ``` You mean you want to specify a path to a package you want to install in chroot, ie a pkg which is not (yet) in repo? I didn't see any usecase for -I, if you can install any built pkg in chroot.
philm commented 2015-05-27 09:08:12 +00:00 (Migrated from gitlab2.manjaro.org)

Created by: Kirek

Yes, its about installing and already built package in the chroot that you only have locally.

Using -n is useful if you do that in succession, but if you have a clean chroot and the package that you want to install, using the -n route would mean rebuilding a package that you already have.

It's not something I always use but from time to time I need to.

Also the functionality is pretty much there, there only thing left to do is pass the argument to mkchrootpkg.

*Created by: Kirek* Yes, its about installing and already built package in the chroot that you only have locally. Using -n is useful if you do that in succession, but if you have a clean chroot and the package that you want to install, using the -n route would mean rebuilding a package that you already have. It's not something I always use but from time to time I need to. Also the functionality is pretty much there, there only thing left to do is pass the argument to mkchrootpkg.
philm commented 2015-05-27 09:28:42 +00:00 (Migrated from gitlab2.manjaro.org)

Created by: udeved

Its ok, we can do a switch wrapper.
I just don't get use case, so its curiosity.

If you have clean chroot, say you want to build lxqt.
You would first have to install liblxqt, after you installed liblxqt, you don't clean chroot, you use the chroot for other packages which need liblxqt and so on. Next time you build lxqt, liblxqt would be in repos.

Its about setting up a build root quickly? I don't get the purpose of installing a local package, except it the initial build before the package goes in repo.

*Created by: udeved* Its ok, we can do a switch wrapper. I just don't get use case, so its curiosity. If you have clean chroot, say you want to build lxqt. You would first have to install liblxqt, after you installed liblxqt, you don't clean chroot, you use the chroot for other packages which need liblxqt and so on. Next time you build lxqt, liblxqt would be in repos. Its about setting up a build root quickly? I don't get the purpose of installing a local package, except it the initial build before the package goes in repo.
philm commented 2015-05-27 09:58:51 +00:00 (Migrated from gitlab2.manjaro.org)

Created by: Kirek

Well for use cases the other day I needed to compile firefox-kde with the nss package that was in arch testing so I downloaded the nss package and used mkchrootpkg with the -I option to do it.

This is not something I usually need, 99% of times I compile a package everything is already in the repos, or can be built in chain, but the rare case that I need it I prefer to be able to use buildpkg directly rather than mkchrootpkg.

*Created by: Kirek* Well for use cases the other day I needed to compile firefox-kde with the nss package that was in arch testing so I downloaded the nss package and used mkchrootpkg with the -I option to do it. This is not something I usually need, 99% of times I compile a package everything is already in the repos, or can be built in chain, but the rare case that I need it I prefer to be able to use buildpkg directly rather than mkchrootpkg.
philm commented 2015-05-31 20:48:16 +00:00 (Migrated from gitlab2.manjaro.org)

Created by: udeved

I haven't tested this.
Does it work @Kirek ?
Can we close this?

*Created by: udeved* I haven't tested this. Does it work @Kirek ? Can we close this?
philm commented 2015-05-31 23:45:35 +00:00 (Migrated from gitlab2.manjaro.org)

Created by: Kirek

It works.

*Created by: Kirek* It works.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
tools/manjaro-tools#98
No description provided.