| Summary: | sys-apps/portage-3.0.57 fetching binpkgs from file:// URI: Unsupported scheme. | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Esteve Varela Colominas <esteve.varela> |
| Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://github.com/gentoo/portage/pull/1215 https://bugs.gentoo.org/show_bug.cgi?id=921208 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 919862 | ||
| Bug Blocks: | 618252, 659784, 768957 | ||
I guess we could add file copy support to BinpkgFetcher. The current system requires that we create a copy (or possibly a hardlink) in PKGDIR. I suppose it would be possible to consume the package without actually adding it to PKGDIR though. Is that something that would be desired? I think it'd make a lot of sense, but to avoid complication I'd stick to copying. If such a feature, where local repositories can be accessed without copying, were to exist, I'd also want it to exist for GENTOO_MIRRORS. (In reply to Esteve Varela Colominas from comment #2) > I think it'd make a lot of sense, but to avoid complication I'd stick to > copying. If such a feature, where local repositories can be accessed without > copying, were to exist, I'd also want it to exist for GENTOO_MIRRORS. Okay, https://github.com/gentoo/portage/pull/1215 adds the copy support. It uses that native file copy extension as long as native-extensions is enabled, which uses reflinks when possible. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=1db44d18578a7aee58449cb97e1991cb06c915c3 commit 1db44d18578a7aee58449cb97e1991cb06c915c3 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2023-12-26 06:42:28 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2023-12-26 06:42:28 +0000 bintree: support file scheme for binhost src-uri Add local file scheme support for binhost src-uri in bintree and BinpkgFetcher. Make BinpkgFetcher use a coroutine to avoid using callbacks. Add AsyncTaskFuture isAlive method that BinpkgFetcher can use to check FileCopier state. Add test command to test emerge -f --getbinpkgonly with local file scheme in binrepos.conf. Also, fix the getbinpkgonly_fetchonly test command so that it does not rename binhost_dir to pkgdir. It seems like it should not do this, and it caused the getbinpkgonly_file_uri command to fail. Bug: https://bugs.gentoo.org/920537 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/_emerge/BinpkgFetcher.py | 117 +++++++++++++++++++---------- lib/portage/dbapi/bintree.py | 19 +++-- lib/portage/tests/emerge/conftest.py | 21 +++++- lib/portage/util/_async/AsyncTaskFuture.py | 8 +- 4 files changed, 111 insertions(+), 54 deletions(-) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0a1f19cdd7a598070b7eb08b3954e677aa4868ad commit 0a1f19cdd7a598070b7eb08b3954e677aa4868ad Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:27:55 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:28:01 +0000 sys-apps/portage: add 3.0.59 Closes: https://bugs.gentoo.org/587088 Closes: https://bugs.gentoo.org/822033 Closes: https://bugs.gentoo.org/915494 Closes: https://bugs.gentoo.org/916135 Closes: https://bugs.gentoo.org/917120 Closes: https://bugs.gentoo.org/919862 Closes: https://bugs.gentoo.org/920095 Closes: https://bugs.gentoo.org/920258 Closes: https://bugs.gentoo.org/920537 Closes: https://bugs.gentoo.org/920654 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.59.ebuild | 246 +++++++++++++++++++++++++++++++++ 2 files changed, 247 insertions(+) |
When configuring my /etc/portage/binrepos.conf with a sync-uri value of file:///path/to/repo, portage is able to properly obtain and parse the Packages file. However, once the merge is accepted, the console ends up filled with messages like the following: file:///home/mid-kid/.gentoo-current/var/cache/binpkgs/sys-libs/libxcrypt/libxcrypt-4.4.36-1.xpak: Unsupported scheme. I feel like having this be supported properly would be very useful, though I would suggest following the formatting for GENTOO_MIRRORS, where an absolute path without scheme is used for local paths.