Bug 1211252

Summary:	Drop the $basearch and $releasever from the cache directory structure
Product:	[Fedora] Fedora	Reporter:	Vít Ondruch <vondruch>
Component:	dnf	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	rawhide	CC:	akozumpl, extras-qa, jdisnard, jorti, jsilhan, mebrown, mluscon, mmraka, msimacek, msuchy, packaging-team-maint, pnemade, praiskup, rholy, tim.lauridsen, vmukhame, vondruch, williams
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:	1173107	Environment:
Last Closed:	2015-07-21 12:34:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Vít Ondruch 2015-04-13 12:32:08 UTC

+++ This bug was initially created as a clone of Bug #1173107 +++

>> 1) Please drop the $basearch and $releasever from the cache directory
>> structure, since they can't protect anything.
>
> Please, file a separate RFE with a reasonable explanation there. Anyway, the > cache structure is something internal to DNF and I doubt you should request
> something like that. You should rather request fixing some problems (see my
> comments to the problems you've mentioned below).

I definitely agree that cache structure is certainly DNF's implementation detail. But I certainly feel obliged to comment on it implementation, since its implementation apparently affects my filesystem space and moreover it indirectly affects what command line parameters DNF enforces.

>> Your point is that if you once specify --releasever=21 and later
>> --releasever=22, then you might be in some troubles. That is nice, you are
>> thinking about some isolated environment where you have everything under
>> control. However, what happens if your configuration file is referring to my
>> repository, which is hosted somewhere on my server and I will do some nasty
>> things to the repository. I might release modified version of some package
>> with the same NVR, I might completely change the content of repository etc.
>> From that POV, you can't be sure about the content of the cache.
>
> Yes, DNF is based on the assumption that the repositories have some
> properties. If you find out that there are some Fedora repositories that
> does not match the assumptions, please file a bug.

I don't doubt about Fedora repositories, but there is plenty of non-Fedora repositories, which certainly don't need --releasever and they might be noarch or they might mix architectures or they might be multiarch.

Please see bug 1173107 for more examples.

Comment 1 Radek Holy 2015-04-13 15:20:27 UTC

The assumptions I was talking about were related to the repository maintainers doing "nasty things to the repository".

The only problem I can see you've reported with repositories that does not need --releasever is the one covered by bug 1211255.

Or maybe... I admit that in bug 1173107, I've made the unfortunate decision to share an implementation detail with you that DNF uses $releasever to build a directory path that is internally used. From the fact that we have not closed the bug you can deduce that although the path structure now contributes to the problem reported in the bug, this is not something we cannot solve.

So, is there any other problem that the cache structure cases to you or should we close this as a duplicate of bug 1211255 or bug 1173107?

Comment 2 Vít Ondruch 2015-04-13 15:45:41 UTC

If the solution is along the lines of bug 1211255, comment 5, i.e. the $releasever is not present in cache directory structure when it is not present in baseurl, then you can indeed close this as a duplicate of bug 1211255, since it should resolve this as well.

Comment 3 Michael Mráka 2015-07-21 12:34:41 UTC


*** This bug has been marked as a duplicate of bug 1211255 ***