Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an ArchiveX header #372

Open
nim-nim opened this issue Dec 13, 2017 · 3 comments
Open

Add an ArchiveX header #372

nim-nim opened this issue Dec 13, 2017 · 3 comments

Comments

@nim-nim
Copy link

nim-nim commented Dec 13, 2017

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
@ffesti ffesti added the RFE label Jun 18, 2018
@ffesti ffesti added this to Needs triage in Ticket Review (Outdated) Mar 3, 2020
@ffesti
Copy link
Contributor

ffesti commented Mar 30, 2020

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

@ffesti ffesti moved this from Needs triage to Yes in Ticket Review (Outdated) Mar 30, 2020
@nim-nim
Copy link
Author

nim-nim commented Mar 31, 2020

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])
    RFE: Add variable arrays to rpm #1149

  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)
    RFE: add variable named scoping to rpm #1150

@kadler
Copy link

kadler commented Aug 19, 2020

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.

@ffesti ffesti self-assigned this May 3, 2021
@ffesti ffesti moved this from Yes to Maybe in Ticket Review (Outdated) Jul 28, 2022
@ffesti ffesti removed their assignment Oct 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Development

No branches or pull requests

3 participants