Bug 1211252 - Drop the $basearch and $releasever from the cache directory structure
Summary: Drop the $basearch and $releasever from the cache directory structure
Keywords:
Status: CLOSED DUPLICATE of bug 1211255
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-13 12:32 UTC by Vít Ondruch
Modified: 2015-07-21 12:34 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1173107
Environment:
Last Closed: 2015-07-21 12:34:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1173107 0 urgent CLOSED mock: use of "dnf --installroot ..." yields "releasever not given" error 2021-02-22 00:41:40 UTC

Internal Links: 1173107

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 ***


Note You need to log in before you can comment on or make changes to this bug.