Bug 27670 - iurt ignores the --chrooted-urpmi option if the repository is on a local file system
Summary: iurt ignores the --chrooted-urpmi option if the repository is on a local file...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Pascal Terjan
QA Contact:
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2020-11-28 13:03 CET by Martin Whitaker
Modified: 2021-09-07 14:10 CEST (History)
1 user (show)

See Also:
Source RPM: iurt-0.7.8-1.mga7.src.rpm
CVE:
Status comment:


Attachments

Description Martin Whitaker 2020-11-28 13:03:26 CET
I discovered this because I wanted to build a package that had dependencies in the nonfree media, for which I used

  --chrooted-urpmi --media core/release nonfree/release -- /path/to/distrib

This change fixes the bug for me

--- Urpmi.pm.orig	2020-11-28 11:42:17.852943434 +0000
+++ Urpmi.pm	2020-11-28 11:39:34.714529062 +0000
@@ -30,7 +30,7 @@
 
 	plog('DEBUG', "installation media: $run->{chrooted_media}");
     }
-    $self->{use__urpmi_root} = !urpm::is_local_url($config->{repository});
+    $self->{use__urpmi_root} = $run->{chrooted_urpmi} || !urpm::is_local_url($config->{repository});
     $self->{distrib_url} = "$config->{repository}/$run->{distro}/$run->{my_arch}";
 
     $self;
Comment 1 Aurelien Oudelet 2020-11-29 12:02:50 CET
urpmi or iurt package?
Patch above is for urpmi...

So assigning correctly.

Assignee: bugsquad => thierry.vignaud
Keywords: (none) => PATCH
CC: (none) => ouaurelien
Source RPM: iurt-0.7.8-1.mga7.src.rpm => urpmi-8.118.2-1.mga7.src.rpm

Comment 2 Martin Whitaker 2020-11-29 12:24:27 CET
No, the above patch applies to /usr/share/perl5/vendor_perl/Iurt/Urpmi.pm.

Reassigning.

Source RPM: urpmi-8.118.2-1.mga7.src.rpm => iurt-0.7.8-1.mga7.src.rpm
Assignee: thierry.vignaud => pterjan

Comment 3 Aurelien Oudelet 2020-11-29 13:02:19 CET
Oh, sorry!
Comment 4 Pascal Terjan 2020-11-29 19:31:20 CET
My understanding is that this is rejected if the main repository is a local directory as it will not be available inside the chroot (chrooted-urpmi means it will run urpmi.addmedia/urpmi/... inside the chroot).

use__urpmi_root means use "urpmi.addmedia --urpmi-root"/... from outside instead. That code is a mess and it should not automatically do such changes to fix incompatible options, but the patch is clearly wrong as it says to always use --urpmi-root from outside whenever someone asks to do the opposite...

--chrooted-urpmi should never be used with local media unless support is added to do a bind mount into the chroot or something like that, why are you trying to use it?
Comment 5 Pascal Terjan 2020-11-29 19:41:09 CET
Interestingly there is support for additional_media being local and getting a bind mount, just not for the main repository, so it would not be too hard to add.

http://gitweb.mageia.org/software/build-system/iurt/tree/lib/Iurt/Chroot.pm#n98
Comment 6 Martin Whitaker 2020-11-29 19:53:06 CET
I think the simple answer to why I'm using --chrooted-urpmi is that I started from here:

https://wiki.mageia.org/en/Packagers_Mentoring_Howto#iurt

and I couldn't find any better documentation.

I have been using iurt with --chrooted-urpmi and a local repository for ages now, and it does work. So I never questioned why it was needed in the examples given on the Wiki.
Comment 7 Martin Whitaker 2020-11-29 20:17:06 CET
Also, if you run iurt without --chrooted-urpmi, it uses the urpmi --root option, which is also running from outside the chroot (but using the urpmi.cfg from outside).
Comment 8 Pascal Terjan 2020-11-29 20:59:03 CET
Actually I didn't remember but it seems I got rid of all calls to "chroot [...] urpmi" in commits like https://gitweb.mageia.org/software/build-system/iurt/commit/lib/Iurt/Urpmi.pm?id=eaa10d73da3e73091949f9a4d6df66a19b03a8e8

So now we always call it from outside at all times with either --urpmi-root or --use-distrib --root.

The current differences as I understand:
- with chrooted_urpmi urpmi.addmedia gets called once, downloading metadata into the chroot
- without chrooted_urpmi --use-distrib is used, downloading metadata for each call for remote media, but never for local ones
- without chrooted_urpmi the options of urpmi outside the chroot get used (for example downloader to use, skip.list).

So apart for performance, the main difference is the urpmi (non media) config.

I think what would make sense would be to decouple those:
- always use urpmi.addmedia into the chroot for remote media, to only download metadata once
- either always use --use-distrib for local media, or bindmount them and also use urpmi.addmedia
- use the option only to decide if we want to use customised urpmi options from outside or the default ones from the chroot

However to really clean things up, options would need to change which would break user scripts / or potentially some other build tools calling iurt.
Comment 9 Martin Whitaker 2020-11-29 21:54:57 CET
So in the meantime, is there a set of options that allows me to build the tainted version of drakx-installer-images from a local repository? I'm currently using

iurt --repository /path/to/distrib --chrooted-urpmi --media core/release nonfree/release -- /path/to/distrib --rpmmacros '%distro_section nonfree' -r cauldron x86_64 <srpm>

but that needs my patch above to make it work.
Comment 10 Pascal Terjan 2020-11-29 23:46:47 CET
I have committed http://gitweb.mageia.org/software/build-system/iurt/commit/?id=8eec3c57d960494cef6939db304a45e72f19b58d to always use urpmi.addmedia + urpmi --urpmi-root

Also the path from --repository is always used (previously it was sometimes used, and sometimes the one from --chrooted-urpmi was used).
Comment 11 Aurelien Oudelet 2021-07-06 13:15:45 CEST
Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.
Comment 12 Marja Van Waes 2021-09-07 14:10:03 CEST
Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.