On Monday, November 30, 2020 1:44:14 PM CET Neal Gompa wrote:
> On Mon, Nov 30, 2020 at 7:41 AM Stephen John Smoogen <firstname.lastname@example.org> wrote:
> > On Mon, 30 Nov 2020 at 06:57, Florian Weimer <email@example.com> wrote:
> >> * Miro Hrončok:
> >> > I was wondering whether it might be possible to use microdnf instead
> >> > of dnf in the boostrap mock chroots. Since dnf depends on Python,
> >> > using the boostrap mode now complicates upgrading Pythons to a newer
> >> > version.
> >> Would it be possible to use rpm-ostree with a vendored RPM
> >> implementation? That should provide even better isolation.
> > koji has a very strong idea of what it wants inside a chroot and what it
> > does not (and may never) want. Getting rpm-ostree or other items to work
> > inside of the koji mock interface is probably looking at a large project
> > (going from how many other 'simple' things have ended up being much more
> > complicated than expected by the original proposers). My usual way of
> > figuring out how to make anything work in koji is to see what the oldest
> > environment it needs to work on by a customer and see how I would do it in
> > RHEL-5 (now maybe RHEL-6).
> Then that's easy: we define a list of packages that are needed to get
> the package manager working, and Koji would just download and unpack
> them with no script execution, then it would manually run some
> predefined scripts and invoke the package manager after that.
Can you elaborate a bit more please? What is the practical difference between
mock's bootstrap chroot and the manual technique you propose?
Koji has to be programmed to know about the mock's bootstrap chroot and be able to use it. Koji 'handwrites' a mock config for every build and calls mock with specific instructions.
I think the manual technique is already built into koji for certain cases but takes configuration on releng to make work. [So the difference would be one is very old, awkward, but there.. the other is a project plan with the koji team.]
> Aside from me doing this before to do RHEL 5 -> RHEL 7 upgrades by
> hand, this is also the strategy used by the openSUSE Build Service to
> work around this problem.
> 真実はいつも一つ！/ Always, there's only one truth!
> buildsys mailing list -- firstname.lastname@example.org
> To unsubscribe send an email to email@example.com
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://firstname.lastname@example.org
buildsys mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com