tools/manjaro-tools

Fork 0

remove package from working copy of the chroot #144

New issue

Closed

opened 2015-09-23 11:11:40 +00:00 by oberon · 13 comments

oberon commented

2015-09-23 11:11:40 +00:00

(Migrated from gitlab2.manjaro.org)

Corresponding to the -i option it would be a great feature to be able to uninstall a certain pkg from the chroot.
At the moment when I build pkg with conflicting dependencies one after the other I have to delete the chroot completely - or am I missing something here?

Corresponding to the -i option it would be a great feature to be able to uninstall a certain pkg from the chroot. At the moment when I build pkg with conflicting dependencies one after the other I have to delete the chroot completely - or am I missing something here?

philm commented

2015-09-23 18:21:14 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: NuLogicSystems

I don't remember an -i option, unless you mean the -n option (Install and run namcap check)?
You could always use the -c option (Recreate chroot) or the -w option (Clean up).

*Created by: NuLogicSystems* I don't remember an -i option, unless you mean the -n option (Install and run namcap check)? You could always use the -c option (Recreate chroot) or the -w option (Clean up).

oberon commented

2015-09-23 18:29:04 +00:00

(Migrated from gitlab2.manjaro.org)

man buildpkg lists -i PKG Install a package into the working copy of the chroot.
Does -c not delete the whole chroot? What exactly will -w do?

man buildpkg lists `-i PKG Install a package into the working copy of the chroot.` Does -c not delete the whole chroot? What exactly will -w do?

philm commented

2015-09-23 18:38:33 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

Usage: buildpkg [options] [--] [makepkg args]
    -p <pkg>           Buildset or pkg [default: default]
    -a <arch>          Arch [default: i686]
    -b <branch>        Branch [default: unstable]
    -r <dir>           Chroots directory
                       [default: /var/lib/manjaro-tools/buildpkg]
    -i <pkg>           Install a package into the working copy of the chroot
    -c                 Recreate chroot
    -w                 Clean up cache and sources
    -n                 Install and run namcap check
    -s                 Sign packages
    -q                 Query settings and pretend build
    -h                 This help

A remove function we don't have yet ...

*Created by: philmmanjaro* ``` Usage: buildpkg [options] [--] [makepkg args] -p <pkg> Buildset or pkg [default: default] -a <arch> Arch [default: i686] -b <branch> Branch [default: unstable] -r <dir> Chroots directory [default: /var/lib/manjaro-tools/buildpkg] -i <pkg> Install a package into the working copy of the chroot -c Recreate chroot -w Clean up cache and sources -n Install and run namcap check -s Sign packages -q Query settings and pretend build -h This help ``` A remove function we don't have yet ...

oberon commented

2015-09-23 18:40:00 +00:00

(Migrated from gitlab2.manjaro.org)

Yes, that's exactly what I mean :)

philm commented

2015-09-23 19:01:13 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: NuLogicSystems

Oops, I apologize. I was looking at the wiki:
https://wiki.manjaro.org/index.php?title=Manjaro-tools#buildpkg

I usually just use -p to build packages.

*Created by: NuLogicSystems* Oops, I apologize. I was looking at the wiki: https://wiki.manjaro.org/index.php?title=Manjaro-tools#buildpkg I usually just use -p to build packages.

philm commented

2015-09-24 15:07:30 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Why do you want to remove a package from chroot?
Can you explain your problem with example?

*Created by: udeved* Why do you want to remove a package from chroot? Can you explain your problem with example?

oberon commented

2015-09-24 15:20:02 +00:00

(Migrated from gitlab2.manjaro.org)

Example: I build conky-i3 which requires conky.
After that I want to build lua-clock-manjaro which requires conky-lua, which conflicts with conky.
I have to delete the chroot to be able to build it.

Example: I build conky-i3 which requires conky. After that I want to build lua-clock-manjaro which requires conky-lua, which conflicts with conky. I have to delete the chroot to be able to build it.

philm commented

2015-09-24 15:22:54 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Yes, recreate chroot is probably best in this case.
Btw, in my view, this can be solved in the conky-lua PKGBUILD eventually, by providing conky.

*Created by: udeved* Yes, recreate chroot is probably best in this case. Btw, in my view, this can be solved in the conky-lua PKGBUILD eventually, by providing conky.

oberon commented

2015-09-24 15:55:37 +00:00

(Migrated from gitlab2.manjaro.org)

Unfortunately not, because conky-lua still uses 1.9 and conky is at 1.10 with new config-syntax 😛 So that means to provide something like buildpkg -R conky is not feasilbe? Like, just the opposite function of -i ? Complicated?

Unfortunately not, because conky-lua still uses 1.9 and conky is at 1.10 with new config-syntax :stuck_out_tongue: So that means to provide something like `buildpkg -R conky` is not feasilbe? Like, just the opposite function of -i <pkg>? Complicated?

oberon commented

2015-09-24 15:57:01 +00:00

(Migrated from gitlab2.manjaro.org)

Would you mind pointing me to the place in the code where the -i option lives?

philm commented

2015-09-24 15:59:02 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Its doable, but the devil is in the details what pacman removal args to use.
Simple _R option could generate errors if other stuff depend on the package.
So, the clean solution is indeed recreating choot in my view.
We'd kind of pollute the chroot I thnk, undermining the purpose of building in chroot, and the chroot could end up like a normal system when makepkg is run.

*Created by: udeved* Its doable, but the devil is in the details what pacman removal args to use. Simple _R option could generate errors if other stuff depend on the package. So, the clean solution is indeed recreating choot in my view. We'd kind of pollute the chroot I thnk, undermining the purpose of building in chroot, and the chroot could end up like a normal system when makepkg is run.

oberon commented

2015-09-24 16:02:53 +00:00

(Migrated from gitlab2.manjaro.org)

Yes I understand :-) thanks!

philm commented

2015-09-24 16:07:36 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

The only case we have to remove a package from chroot is when building eudev stuff, so libsystemd has to go from chroot. I am thinking about a way to improve this with fake groups.

*Created by: udeved* The only case we have to remove a package from chroot is when building eudev stuff, so libsystemd has to go from chroot. I am thinking about a way to improve this with fake groups.