Am 29.01.2025 um 10:08 schrieb Stefan Herbrechtsmeier via
lists.openembedded.org:
Am 28.01.2025 um 16:23 schrieb Richard Purdie:
On Tue, 2025-01-28 at 09:46 +0100, Stefan Herbrechtsmeier via
lists.openembedded.org wrote:
I have overseen the usage of a regex for the PREMIRROR. The current
usage has implicit assumption which makes a change complicated.
The following lines only works because we assume that we must append
the mirrortarball if the scheme is changed:
git://.*/.*https://downloads.yoctoproject.org/mirror/sources/
ftp://.*/.*https://downloads.yoctoproject.org/mirror/sources/
The following line only works because we don’t define a mirrortarball
and append the basename:
http://.*/.*https://downloads.yoctoproject.org/mirror/sources/
The problem is the implicit MIRRORTARBALL and BASENAME replacement
variable at the end of the path. This makes it impossible to know if
the PREMIRROR provides a mirror of the source server or serves the
download folder.
PREMIRROR is meant to be the download folder.
The PREMIRROR could also be used to use a private package manager
proxy / registry:
https://registry.npmjs.org https://example.org/npm
Is this an unintended usage?
The idea was that http could be mapped directly but something like git
would use mirror tarballs. Fetchers that need mirror tarballs would
expose those and the code would work accordingly. The behaviour could
be fetcher backend specific for the mirror tarballs.
Ok, so mirrortarball and downloadfilename have different meanings.
That was the design. Whether everything still works like that is
unknown.
What was the design of downloadfilename? Based on the name and the
code it looks like the intention was a filename without sub directories.
The gomod fetcher needs the possibility to avoid name clashes in the
download directory and copy (unpack=0) the download with the original
name. Either the downloadfilename allows sub directories or the
unpack=0 parameter supports a rename of the copied download archive.
The sstate fetch already use downloadfilename with sub directories but
thereby the path on server and download folder match.
Bitbake only replaces the last part (basename) of the uri. Shouldn't
bitbake track the relative path (downloadfilename) and replace it.
Additionally bitbake always replaces or adds the basename of the
downloadfilename / localpath. Is this a desired behavior because it
prevent upstream mirrors.
Example:
SRC_URI =
"https://registry.npmjs.org/@abc/def/-/def-1.2.3.tgz;[email protected]";
MIRROR = "https://registry.npmjs.org/ https://exampe.com/npm/\n";
==> https://exampe.com/npm/@abc/def/-/@abc-def-1.2.3.tgz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2120):
https://lists.openembedded.org/g/openembedded-architecture/message/2120
Mute This Topic: https://lists.openembedded.org/mt/110806536/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
