> This is a valid use case. But I dislike the idea of adding a new tag for
> this. I'd rather like to see something that is closer to the hack without its
> drawbacks
> `Source1: https://foo.bar/baz -> ba-1.2.tgz` or
> `Source1: https://foo.bar/baz : ba-1.2.tgz`
I definitely like this better tha
While anything would be better than the current situation, from a rpm user POW,
I'd like less magic and special things in rpm, and more generic operators and
constructs.
IE, everything is a variable, except for things that need multiple
declarations, and use tags.
SourceX as a tag is IMHO a m
This is a valid use case. But I dislike the idea of adding a new tag for this.
I'd rather like to see something that is closer to the hack without its
drawbacks
`Source1: https://foo.bar/baz -> ba-1.2.tgz` or
`Source1: https://foo.bar/baz : ba-1.2.tgz`
--
You are receiving this because you are
The URL in a SourceN: tag is informative only, specifying where the tarball
came from.
Meanwhile, only the basename(2) of that URL has ever been used or needed by
rpmbuild.
The basename is appended to %_sourcedir where the tarball (or other source) is
expected.
There is no reason whatsoever th
Right now rpm assumes it can scrap the archivex filename from SourceX, but
nowadays many upstreams publish source archives on URLs that do not contain the
actual archive name*
The common workaround is to change SourceX to url#/archivex filename, but that
is quite confusing to new packagers and
