Make %setup defaults smarter

[nim-nim]

Right now %setup assumes archives contain a %{name}-%{version} topdir which is pretty stupid.

The probability anyone will create an archive containing a %{name}-%{version} topdir while not named %{name}-%{version} is vanishingly small.

%setup should assume the topdir is named the same as the archive (after removing known extensions), which will work in 90% of the cases, including when the archive is itseld named %{name}-%{version}

[herrold]

The probability anyone will create an archive containing a %{name}-%{version} topdir while not named %{name}-%{version} is vanishingly smal

My build tools do this 'different %_topdir naming' on ** every ** build

It might make sense to actually use rpmbuild for a decade or so before proposing changes that break backward compatibility

[nim-nim]

You have build your toolset around rpm quirks in the meanwhile in the actual world that almost never happens

And I've been using rpm for two decades (if you want a pissing contest)

[herrold]

No 'quirks' at all ... I have built my tools with the rpm and rpmbuild man pages open, and consulting:

rpm --showrc

That's how developing in an Unixy (tm) environment works

I know what is not a good idea on the Usenet ... ahh, times change so silly me, having been the editor of RPM.ORG during the JBJ maintainer-ship with the almost obsessive attention to preserving backward compatibility, and keeping that documentary content alive out of my own pocket, when RH re-pointed the domain to Seth at Duke, and then pulled it back in house

http://www.oldrpm.org/

silly, in having forgotten your contributions

< sarcasm > probably early onset senility on my part </>

[nim-nim]

Surely you do not mean that literally, where the directory name has, say, the suffix ".tar.gz"
or ".zip" appended in the directory name.

Yes, sure, that was shorthand, the issue text is more explicit

Also note that SourceN: is used for content that may not be an archive at all.

Then those SourceNs won't need an ArchiveN, I propose an Optional ArchiveN which makes only sense for source archives (which are still the main SourceN kind)

No 'quirks' at all ... I have built my tools with the rpm and rpmbuild man pages open, and
consulting:

Yes, right. Then you won't have any problem finding hundreds of packages that follow your pattern in the thousands Fedora or Suse packages ? More numerous than the thousands that use GitHub (for example) as SourceN ?

[herrold]

Yes, right. Then you won't have any problem finding hundreds of packages

Under the present system, my tooling runs and provides sub-second look-ups on a corpus of (today) 796479 packagings

Stop picking a fight

[pmatilai]

Seems the actual request was totally misunderstood by somebody here...

Anyway, the issue is that there's no way to make such a thing reliable, and we can't really turn a long-standing explicit known behavior into a heuristic. In general, heuristics don't work very well in rpm. Stripping out known extensions seems like a simple task to a human, but in software that knowledge would be a hardcoded list, and we're not going to maintain such a thing in rpm.