Re: [Rpm-maint] [rpm-software-management/rpm] Add an ArchiveX header (#372)
> 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 than having a separate "ArchiveX" tag to correlate things. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/372#issuecomment-676516379___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add an ArchiveX header (#372)
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 mistake, for example. You'll never need to declare
it multiple time, since you need a unique name to attach special setup actions
to. So special tag + special operator does not improve things a lot.
Generic constructs help automating a lot, special constructs need special
handling, that always neem to hit corner cases.
So as a long term direction, I'd like unique name tags to be slowly deprecated
and replaced by unique name variables with generic variable set/unset behaviour.
And, for Tags that can not be converted to variables right now, because they
*need* the multiple declaration property, I’d like rpm to grow *generic*
multi-declaration primitives.
1. for Tags that are multi-declared as a poor man way to create arrays: add
real rpm variable arrays (`%set array [a,b,c]`, `%append array [d,e]`, `%array
%= [a,b,c]`, `%array %+= [d,e]`)
2. for Tags that multi-declared as part of a subpackage scope: create a real
`%{scope(subpackage): }` primitive (that’s just a generalisation of the `-n`
used by `%package`, `%description`, `%files`, etc, except without needing a
separate flag per line, and without all the bugs when you cut and paste and
forget to change the `-n` value on one of the lines)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/372#issuecomment-606542947___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add an ArchiveX header (#372)
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 subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/372#issuecomment-605953186___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add an ArchiveX header (#372)
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 that you cannot use SourceN: as if it were your proposed ArchiveX: tag, particularly for those circumstances where there is no upstream link that contains a tarball (or other source). Appending #/archiveX has the distinct advantage of being backward compatible to all versions of rpm build, unlike your proposed addition of an ArchiveX: tag, which would create instant incompatibility with all deployed versions of RPM. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/372#issuecomment-351525306___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add an ArchiveX header (#372)
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 creates artificial urls which are very hard to parse and maintain, are error-prone, have the risk that the website will interpret them differently from rpm rpm should bite the bullet and allow for each SourceX an optional corresponding ArchiveX, with the following semantics: 1. if archiveX exists set the filename of SourceX to archiveX 2. if it does not scrap the filename of SourceX the same way it's done today -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/372___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
