7:38 a.m.
Hi,
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d
In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have
sense to keep `yum.repos.d`.
DNF for ages parse config files from:
{"/etc/yum.repos.d", "/etc/yum/repos.d",
"/etc/distro.repos.d"}
Therefore the move of repo files does not require any change in DNF. It should be just
change in fedora-repos.
If anyone put his private repos to /etc/yum.repos.d then DNF will parse it too. From DNF
point of view, the files can be
split randomly across all those directories.
Of course, that directory is mentioned everywhere in documentation and it will take ages
to change it as it is written
everywhere. But the other option is to stuck with yum.repos.d forever.
Is there anything which can block this move?
Miroslav
7:41 a.m.
On Wed, Mar 13, 2019 at 8:39 AM Miroslav Suchý <msuchy(a)redhat.com> wrote:
Hi,
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d
In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have
sense to keep `yum.repos.d`.
DNF for ages parse config files from:
{"/etc/yum.repos.d", "/etc/yum/repos.d",
"/etc/distro.repos.d"}
Therefore the move of repo files does not require any change in DNF. It should be just
change in fedora-repos.
If anyone put his private repos to /etc/yum.repos.d then DNF will parse it too. From DNF
point of view, the files can be
split randomly across all those directories.
Of course, that directory is mentioned everywhere in documentation and it will take ages
to change it as it is written
everywhere. But the other option is to stuck with yum.repos.d forever.
Is there anything which can block this move?
Nothing except bikeshedding. :)
That said, I think if we want to move the repo files now, we should
also consider making so package installed repo and GPG files are in
/usr/share and that admin additions/overrides can be stored in /etc.
Same goes for vars and other such stuff.
That's more or less the mechanism we've adopted for tons of other
things, and it'd be nice to have it in DNF too...
--
真実はいつも一つ！/ Always, there's only one truth!
8:03 a.m.
On Wed, Mar 13, 2019 at 1:42 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Mar 13, 2019 at 8:39 AM Miroslav Suchý <msuchy(a)redhat.com> wrote:
>
> Hi,
> I am curious whether we can move our repo files from
> /etc/yum.repos.d
> to
> /etc/distro.repos.d
Why not /etc/dnf/repos.d and a symlink for /etc/yum.repos.d?
> In Fedora 31 we are going to wipe away last left overs of YUM,
so it really does not have sense to keep `yum.repos.d`.
>
> DNF for ages parse config files from:
> {"/etc/yum.repos.d", "/etc/yum/repos.d",
"/etc/distro.repos.d"}
> Therefore the move of repo files does not require any change in DNF. It should be
just change in fedora-repos.
> If anyone put his private repos to /etc/yum.repos.d then DNF will parse it too. From
DNF point of view, the files can be
> split randomly across all those directories.
>
> Of course, that directory is mentioned everywhere in documentation and it will take
ages to change it as it is written
> everywhere. But the other option is to stuck with yum.repos.d forever.
>
> Is there anything which can block this move?
>
Nothing except bikeshedding. :)
That said, I think if we want to move the repo files now, we should
also consider making so package installed repo and GPG files are in
/usr/share and that admin additions/overrides can be stored in /etc.
Same goes for vars and other such stuff.
Agreed, but it would be nice to have tooling to list repos, see their
origin and whether or not they were overridden.
That's more or less the mechanism we've adopted for tons of
other
things, and it'd be nice to have it in DNF too...
Wasn't systemd the catalyst for this?
Dridi
2:41 p.m.
On 3/13/19 8:41 AM, Neal Gompa wrote:
That said, I think if we want to move the repo files now, we should
also consider making so package installed repo and GPG files are in
/usr/share and that admin additions/overrides can be stored in /etc.
Same goes for vars and other such stuff.
That's more or less the mechanism we've adopted for tons of other
things, and it'd be nice to have it in DNF too...
Yes! This.
I would also suggest that the canonical location be defined in another
file whose name is as immutable as possible. If there were a central
file that held such important locations and all tools consulted that
first, these kind of changes would be far less painful. I'm thinking
along the lines of the blessed sanity that /etc/os-release brings.
Obviously it'll take a long time for it to have the far reaching
benefits it could provide, but if we never start down that path...
7:50 a.m.
On 3/13/19 13:38, Miroslav Suchý wrote:
Hi,
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d
In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have
sense to keep `yum.repos.d`.
DNF for ages parse config files from:
{"/etc/yum.repos.d", "/etc/yum/repos.d",
"/etc/distro.repos.d"}
Therefore the move of repo files does not require any change in DNF. It should be just
change in fedora-repos.
If anyone put his private repos to /etc/yum.repos.d then DNF will parse it too. From DNF
point of view, the files can be
split randomly across all those directories.
Of course, that directory is mentioned everywhere in documentation and it will take ages
to change it as it is written
everywhere. But the other option is to stuck with yum.repos.d forever.
Is there anything which can block this move?
Please don't, it's just pointless renaming that invalidates all end user
documentation and makes it harder for other programs such as packagekit
and gnome-software that all need to adopt for the new paths.
Also, I've heard rumours that dnf might get renamed back to yum in the
future.
--
Kalev
9:36 a.m.
Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a):
Please don't, it's just pointless renaming that invalidates
all end user
documentation and makes it harder for other programs such as packagekit
and gnome-software that all need to adopt for the new paths.
Not exactly true.
When documentaion state: put this file in /etc/yum.repos.d/ ... then it will be still
valid. DNF will read that file
without a problem.
We *may* start slowly change these documentation to "put this file in
/etc/distro.repos.d".
Only invalid statement will be "fedora.repo is in /etc/yum.repos.d/"
Miroslav
9:49 a.m.
On Wed, 13 Mar 2019 at 14:37, Miroslav Suchý <msuchy(a)redhat.com> wrote:
Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a):
> ..makes it harder for other programs such as packagekit
> and gnome-software that all need to adopt for the new paths.
Not exactly true.
It's completely true, Kalev is spot on. GNOME Software reads files in
/etc/yum.repos.d to match up repo names to URLs. If there are two
directories, we'll need to modify both PackageKit and gnome-software.
It's completely pointless in my opinion.
Richard.
10:07 a.m.
On Wed, Mar 13, 2019 at 10:37 AM Miroslav Suchý <msuchy(a)redhat.com> wrote:
Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a):
> Please don't, it's just pointless renaming that invalidates all end user
> documentation and makes it harder for other programs such as packagekit
> and gnome-software that all need to adopt for the new paths.
Not exactly true.
When documentaion state: put this file in /etc/yum.repos.d/ ... then it will be still
valid. DNF will read that file
without a problem.
We *may* start slowly change these documentation to "put this file in
/etc/distro.repos.d".
Only invalid statement will be "fedora.repo is in /etc/yum.repos.d/"
This isn't a great experience, though. It's kind of nice having all
the repository files in one place-- it means that if I want to find
out which repositories are enabled or installed without actually using
dnf, I can just look at the contents of a single directory.
Breaking that up into two+ directories will just make this slightly
more difficult and annoying. This might be okay if there was a strong
reason in favor of making the change, but it's not clear to me that
there is one beyond a desire to get away from using the name "yum".
Ben Rosser
10:03 a.m.
On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember <kalevlember(a)gmail.com>
wrote:
Please don't, it's just pointless renaming that invalidates
all end
user
documentation and makes it harder for other programs such as
packagekit
and gnome-software that all need to adopt for the new paths.
Handling a rename is not exactly rocket science. Why would this be at
all problematic? The change is proposed for F31, not F30. That's plenty
of time. If this is the last remaining usage of "yum" in the distro
then let's get rid of it and move on. Since both locations should be
read, it should be fully backwards-compatible anyway.
Also, I've heard rumours that dnf might get renamed back to yum
in the
future.
Do the dnf developers know about this rumor...?
Michael
10:46 a.m.
On 3/13/19 4:03 PM, mcatanzaro(a)gnome.org wrote:
On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember
<kalevlember(a)gmail.com>
wrote:
> Please don't, it's just pointless renaming that invalidates all end user
> documentation and makes it harder for other programs such as packagekit
> and gnome-software that all need to adopt for the new paths.
Handling a rename is not exactly rocket science. Why would this be at
all problematic? The change is proposed for F31, not F30. That's plenty
of time. If this is the last remaining usage of "yum" in the distro then
let's get rid of it and move on. Since both locations should be read, it
should be fully backwards-compatible anyway.
It is reasonable to introduce a better name for the repo and
/etc/distro.repos.d seems to be a nice and clearer one. It furthermore
somewhat stresses that it is not related to a specific tool (yum) which
is indeed the case since packagekit and others also use it.
So creating the new directory (1) -- provided everyone agrees on the
name -- and putting the repo files in it is nice and not complicated or
dangerous.
A different question is migration of all tools/documentation to this new
directory. Fortubately, there is a simple solution. Make a symbolic link
from the old directory to the new. Adding this symbolic link (2) ensures
that everything works smoothly immediately (and conveys the message that
the "true" directory changed).
A third question (3) is when to suppress the symbolic link. Nothing
requires that this is immediate (except eventually some aesthetics). It
can last as long as needed to ensure that all tools are migrated and
that the name change is sufficiently documented (there will be always
old web ressources that will remain with the old name, but if the new
name appears often enough on web searches, that's OK).
I believe that (1) and (2) can be done immediately and could be consensual.
(3) can be dealt much later....
Theo.
1:35 p.m.
If anything of the like, /etc/dnf.repos.d makes more sense. These repos are not
necessarily part of the distro.
On March 13, 2019 11:46:12 AM EDT, Theodore Papadopoulo
<Theodore.Papadopoulo(a)inria.fr> wrote:
On 3/13/19 4:03 PM, mcatanzaro(a)gnome.org wrote:
> On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember <kalevlember(a)gmail.com>
> wrote:
>> Please don't, it's just pointless renaming that invalidates all end
user
>> documentation and makes it harder for other programs such as
packagekit
>> and gnome-software that all need to adopt for the new paths.
>
> Handling a rename is not exactly rocket science. Why would this be at
> all problematic? The change is proposed for F31, not F30. That's
plenty
> of time. If this is the last remaining usage of "yum" in the distro
then
> let's get rid of it and move on. Since both locations should be read,
it
> should be fully backwards-compatible anyway.
It is reasonable to introduce a better name for the repo and
/etc/distro.repos.d seems to be a nice and clearer one. It furthermore
somewhat stresses that it is not related to a specific tool (yum) which
is indeed the case since packagekit and others also use it.
So creating the new directory (1) -- provided everyone agrees on the
name -- and putting the repo files in it is nice and not complicated or
dangerous.
A different question is migration of all tools/documentation to this
new
directory. Fortubately, there is a simple solution. Make a symbolic
link
from the old directory to the new. Adding this symbolic link (2)
ensures
that everything works smoothly immediately (and conveys the message
that
the "true" directory changed).
A third question (3) is when to suppress the symbolic link. Nothing
requires that this is immediate (except eventually some aesthetics). It
can last as long as needed to ensure that all tools are migrated and
that the name change is sufficiently documented (there will be always
old web ressources that will remain with the old name, but if the new
name appears often enough on web searches, that's OK).
I believe that (1) and (2) can be done immediately and could be
consensual.
(3) can be dealt much later....
Theo.
--
Sent from my mobile device. Please excuse my brevity.
5:31 a.m.
If anything of the like, /etc/dnf.repos.d makes more sense. These
repos are not
necessarily part of the distro.
Please don't tie the name with the particular software to avoid this issue in the
future. If you must then I think rpm.repos.d is less likely to avoid this issue in the
future.
6:32 a.m.
On Fri, Mar 15, 2019 at 11:32 AM Samuel Rakitničan
<srakitnican(a)fedoraproject.org> wrote:
Please don't tie the name with the particular software to avoid
this issue in the future. If you must then I think rpm.repos.d is less likely to avoid
this issue in the future.
+1
Just like a few others have mentioned in this thread, I too consider
the choice of "dnf" for a package manager quite unfortunate. It does
not really stand for anything (except for the notorious Did Not
Finish).
For the same reasons why "systemd" or any other basic system utilities
are not named after some random spur-of-the-moment sequence of
characters or words, *the* package manager on a UNIX-like system,
something that's really at the core of system administration, should
also prefer a sensible name such as "pkg" or similar.
In case of "dnf", I understand that one of the reasons was to make it
easy to touch-type, which it is (as opposed to "yum"), but that
quality is not in contradiction with the choice of a more descriptive
(yet short and simple) name. The name is fine for an experimental
project but those days are long gone and dnf is now the de-facto
successor of yum.
That said, if we should pick a different name today, "yum" seems like
the most sensible choice. While still far from ideal, it has
stickiness within the Fedora/RHEL community, and is a "trademark",
really.
--
Michal Domonkos
Software Engineer, DNF stack
Red Hat, Inc.
9:13 a.m.
On 3/15/19 12:32 PM, Michal Domonkos wrote:
That said, if we should pick a different name today, "yum"
seems like
the most sensible choice. While still far from ideal, it has
stickiness within the Fedora/RHEL community, and is a "trademark",
really.
Yesterday's Updater Modified
:-)
--
Roberto Ragusa mail at robertoragusa.it
9:38 a.m.
`rpm` does not care what repositories your system has available, it doesn't work with
them directly. That name would make no sense.
On March 15, 2019 6:31:40 AM EDT, "Samuel Rakitničan"
<srakitnican(a)fedoraproject.org> wrote:
> If anything of the like, /etc/dnf.repos.d makes more sense.
These
repos are not
> necessarily part of the distro.
Please don't tie the name with the particular software to avoid this
issue in the future. If you must then I think rpm.repos.d is less
likely to avoid this issue in the future.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Sent from my mobile device. Please excuse my brevity.
10:35 a.m.
On Fri, Mar 15, 2019 at 3:39 PM John M. Harris, Jr.
<johnmh(a)splentity.com> wrote:
`rpm` does not care what repositories your system has available, it doesn't work with
them directly. That name would make no sense.
I guess the rationale behind that was more of a "repositories of rpm
packages" than "repositories used by rpm(8)".
--
Michal Domonkos
Software Engineer, DNF stack
Red Hat, Inc.
12:10 p.m.
mcatanzaro(a)gnome.org wrote:
On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember
<kalevlember(a)gmail.com>
wrote:
> Also, I've heard rumours that dnf might get renamed back to yum in the
> future.
Do the dnf developers know about this rumor...?
In recent Fedora releases DNF has stopped complaining when it's invoked
as "yum". /usr/bin/yum is provided by the package dnf-yum, produced
from the source package dnf, so apparently at least the packagers of
DNF know about it.
It was discussed on this list last June. The renaming to DNF never
happened in RHEL/CentOS. It's Yum in RHEL 7 and (I hear) it will be Yum
in RHEL 8. Presumably the reason for this is that the sysadmins who
manage RHEL systems like continuity, dislike pointless renaming, and
really hate having to remember to type "dnf" on some servers and
"yum"
on others for no good reason.
Björn Persson
5:54 a.m.
On 3/13/19 6:10 PM, Björn Persson wrote:
It was discussed on this list last June. The renaming to DNF never
happened in RHEL/CentOS. It's Yum in RHEL 7 and (I hear) it will be Yum
in RHEL 8. Presumably the reason for this is that the sysadmins who
manage RHEL systems like continuity, dislike pointless renaming, and
really hate having to remember to type "dnf" on some servers and
"yum"
on others for no good reason.
Renaming dnf to yum is IMHO the best option.
I constantly use the wrong tool when switching between Fedora and Centos,
and the painful "yum.repos.d" string issue (code + docs) would disappear.
Considering that yum has no future and that the options are sufficiently
similar, why not just consider dnf as a new and slightly incompatible yum
version.
(remember egcs -> gcc many years ago)
Regards.
--
Roberto Ragusa mail at robertoragusa.it
4:34 a.m.
On Thu, Mar 14, 2019 at 11:56 AM Roberto Ragusa <mail(a)robertoragusa.it> wrote:
Renaming dnf to yum is IMHO the best option.
I constantly use the wrong tool when switching between Fedora and Centos,
and the painful "yum.repos.d" string issue (code + docs) would disappear.
Actually, we're planning [1] to rename the "dnf-yum" subpackage to
"yum" in Fedora 31, to stay more consistent with the RHEL/CentOS
world. That way, once Fedora 31 is out, those who have the original
"yum" installed would just seamlessly upgrade to the new major version
4 (the former "dnf-yum"). That's about as close as we can get to
renaming dnf to yum in Fedora at this moment.
Note that the original yum config files would not be automatically
migrated or merged into their dnf counterparts (except for
/etc/yum.repos.d which is used by dnf already), but that's not the
goal here either, as it would be quite complex and error-prone (at a
minimum, we would have to incorporate a pretrans scriptlet using Lua
[2] to take care of some of the symlinks). Instead, we just want to
provide a smooth upgrade path for yum in Fedora for those who happen
to still be using it for one reason or another, however the actual
config migration (if needed) would have to be done manually by each
user.
IOW, the plan is that the "yum" package will continue to live on both
distros, although the compatibility level of this package will differ
between the two; on Fedora, it will only ship the /usr/bin/yum symlink
and the yum(8) man page, just like the former "dnf-yum".
The whole situation may seem complicated right now, but using the same
package name for the yum compatibility layer on both Fedora and
RHEL/CentOS should simplify things a little bit.
[1] https://github.com/rpm-software-management/dnf/pull/1337
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Repla...
--
Michal Domonkos
Software Engineer, DNF stack
Red Hat, Inc.
3:13 p.m.
On Wed, 13 Mar 2019 at 08:51, Kalev Lember wrote:
Also, I've heard rumours that dnf might get renamed back to yum in the
future.
I just hope that dnf gets renamed to something easier. It doesn't
stick as good as yum, apt or pacman. Anything other than yum will be a
lot of work though.
Orcan
9:52 a.m.
Le mer. 13 mars 2019 à 13:39, Miroslav Suchý <msuchy(a)redhat.com> a écrit :
Hi,
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d
I don't see the point to "change" this directory for "pleasure" if
it
doesn't come with more features.
Right now yum.repos.d should be understood by "yum or compatible"
repository definitions.
I'm totally against using /etc/distro.repos.d as such.
Now if we can have a way to distribute default distro repos in
/usr/lib/distro.repos.d/fedora.repo and to be able to override some
options in /etc/distro.repos.d/fedora.repo such as (1).
Then it might be interresting behavior change.
(1)
[fedora]
enabled=0/1
baseurl=myinternalmirror.example.net
etc.
12:07 p.m.
Miroslav Suchý wrote:
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d
Please, no. Sysadmins don't like having to change their habits, scripts
and documents for no benefit because somebody renamed something just for
the sake of renaming. Pointless changes cost time and money that could
have been spent doing useful work instead.
Björn Persson
3:36 p.m.
On Wed, 2019-03-13 at 13:38 +0100, Miroslav Suchý wrote:
Hi,
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d
In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have
sense to keep `yum.repos.d`.
DNF for ages parse config files from:
{"/etc/yum.repos.d", "/etc/yum/repos.d",
"/etc/distro.repos.d"}
Therefore the move of repo files does not require any change in DNF. It should be just
change in fedora-repos.
If anyone put his private repos to /etc/yum.repos.d then DNF will parse it too. From DNF
point of view, the files can be
split randomly across all those directories.
Of course, that directory is mentioned everywhere in documentation and it will take ages
to change it as it is written
everywhere. But the other option is to stuck with yum.repos.d forever.
Is there anything which can block this move?
Well, any script which does anything to the Fedora repo config and
assumes it will be in /etc/yum.repos.d , for a start. (Our openQA tests
do this, for one thing.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:34 a.m.
Hi,
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d
In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have
sense to keep `yum.repos.d`.
DNF for ages parse config files from:
{"/etc/yum.repos.d", "/etc/yum/repos.d",
"/etc/distro.repos.d"}
Therefore the move of repo files does not require any change in DNF. It should be just
change in fedora-repos.
If anyone put his private repos to /etc/yum.repos.d then DNF will parse it too. From DNF
point of view, the files can be
split randomly across all those directories.
Of course, that directory is mentioned everywhere in documentation and it will take ages
to change it as it is written
everywhere. But the other option is to stuck with yum.repos.d forever.
Is there anything which can block this move?
This has been discussed in the past and was overwhelming agreed to be
a bad idea and just change for changes sake. Please don't.
1866
days inactive
1868
days old
25 comments
19 participants
participants (19)
-
Adam Williamson -
Ben Rosser -
Björn Persson -
Dridi Boukelmoune -
John Florian -
John M. Harris, Jr. -
Kalev Lember -
mcatanzaro＠gnome.org -
Michal Domonkos -
Miroslav Suchý -
Neal Gompa -
Nicolas Chauvet -
Orcan Ogetbil -
Peter Robinson -
Rex Dieter -
Richard Hughes -
Roberto Ragusa -
Samuel Rakitničan -
Theodore Papadopoulo