= Proposed System Wide Change: Replace Yum With DNF = https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
Note: This is Fedora 22 proposal!
Change owner(s): Aleš Kozumplík kozumplik@gmail.com
Make DNF/Yum4 the new default packaging tool in F22.
== Detailed Description == DNF was forked from Yum in January 2012 and available for experimenting in Fedora since release 18 [1]. The project is now fully capable of replacing Yum in new Fedora installations. We want DNF to become the new default packaging tool in Fedora 22. This entails:
* letting system administrators (including users who routinely manage their packages using the legacy Yum) perform all common packaging operations using DNF, with no or minimal and documented [2] change to the command syntax, apart from replacing the command name. (done) * providing implementation of Anaconda backend so system can be bootstrapped completely without using legacy Yum. (done) * providing alternative to all Yum plugins from yum-utils (ongoing) * providing alternative to all release engineering tools (repoquery, bodhi etc.) from yum-utils (ongoing) * being ready/having the capacity to help out users with migration of their custom legacy plugins and extensions to DNF. The solid API documentation [3] we provide is of great advantage here. (ongoing)
In practice, the change implies: * Anaconda installs the system using the DNF backend (with no special switches) * package 'dnf' is installed by default (referenced by the base comps groups) * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own <code>/usr/bin/yum</code>, a short script that redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users.
== Scope == This change will be completely transparent for users that use only the graphical package management tools. For anybody using the command line directly there will be some differences, but all the important operations are available with DNF, using the same CLI syntax.
* Proposal owners: The majority of tasks on this change are completed. Some plugins and API calls still need to be added. The Anaconda payload implementation needs more testing, Fedora Test Day for this is pending.
* Other developers: We provide the paylaod implementation for Anaconda developers. Developers of other extensions and developers of plugins that are not part of yum-utils will have to update their code.
* Release engineering: Release engineering tools that are internal to the releng teams and not part of yum-utils will need modifications to migrate to the DNF API.
* Policies and guidelines: None at the moment.
[1] https://fedoraproject.org/wiki/Features/DNF [2] http://akozumpl.github.io/dnf/cli_vs_yum.html [3] http://akozumpl.github.io/dnf/api.html _______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum
and provides its own <code>/usr/bin/yum</code>, a short script that redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
Hi
On Wed, Jun 11, 2014 at 8:52 AM, Matthew Miller wrote:
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except some of the command line changes which happened with yum anyway (download only was added and later removed for example) and one can warn specifically for those. The API changes are not something users care about. Also, dnf needs to drop all the legacy options before the transition (ie) pick erase or remove (preferably the latter) etc rather than retain all the compatibility options.
Rahul
On 11. 6. 2014 at 09:02:29, Rahul Sundaram wrote:
Hi
On Wed, Jun 11, 2014 at 8:52 AM, Matthew Miller wrote:
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This
also
seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every
time
it is used?
I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except
some
of the command line changes which happened with yum anyway (download
only
was added and later removed for example) and one can warn specifically for those. The API changes are not something users care about. Also, dnf needs to drop all the legacy options before the transition (ie) pick erase or remove (preferably the latter) etc rather than retain all the compatibility options.
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf.
Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations.
Thanks Jan
Hi
On Wed, Jun 11, 2014 at 11:20 AM, Jan Zelený wrote:
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf.
I would suggest doing it the other way around. Rename old yum to yum-legacy. Rename dnf to yum and at the end of the transition period drop yum-legacy and retain yum as the command line name. For any deprecation options, warn on them and suggest the supported alternative. With your current plan, after the transition period, everyone has to retrain themselves to type dnf instead of yum which I don't think is necessary.
Rahul
On Wed, Jun 11, 2014 at 11:25:31AM -0400, Rahul Sundaram wrote:
Hi
On Wed, Jun 11, 2014 at 11:20 AM, Jan ZelenA 1/2 wrote:
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf.I would suggest doing it the other way around.A A Rename old yum to yum-legacy.A Rename dnf to yum and at the end of the transition period drop yum-legacy and retain yum as the command line name.A A For any deprecation options, warn on them and suggest the supported alternative.A With your current plan, after the transition period, everyone has to retrain themselves to type dnf instead of yum which I don't think is necessary.A
If the idea is interesting it does imply that each person having scripts depending on yum has to: * s/yum/yum-legacy/ - Deploy to prod and run as before * s/yum-legacy/dnf/ - Test and ensure it has a consistent behavior w/ yum (that the script is not using any of the deprecated options, that there is no some surprises in some weird corners)
So the scripts need to be updated twice against once if we just let dnf be dnf and eventually let it provide a /usr/bin/yum optionally.
Pierre
On 06/11/2014 06:13 PM, Pierre-Yves Chibon wrote:
If the idea is interesting it does imply that each person having scripts depending on yum has to:
- s/yum/yum-legacy/
- Deploy to prod and run as before
- s/yum-legacy/dnf/
- Test and ensure it has a consistent behavior w/ yum (that the script is not using any of the deprecated options, that there is no some surprises in some weird corners)
Nope. It means that once /usr/bin/yum become symlink (or wrapper) to dnf, then either: 1) nothing will change because dnf is mostly compatible will yum. I would say this will be behavior for majority of existing scripts. 2) your script use some corner case of yum and will become broken. And you either a) migrate immediately to DNF b) you (the-sysadmin) are lazy and put it on back-burner and do s/yum/yum-legacy/ and you have to do that work from a) anyway one year later.
Am 12.06.2014 10:51, schrieb Miroslav Suchý:
b) you (the-sysadmin) are lazy and put it on back-burner and do s/yum/yum-legacy/ and you have to do that work from a) anyway one year later
stop people calling lazy because they are not accepting replacements which are not drop-in
Fedora would most likely not exist if the decades before Unix/Linux would have changed it's behavior every few months - the "we rename and replace everything all few months and looking how to replace it in a way everybody takes notice of our work" is a more or less new phenomenon, in the past developers where proud of keep interface stability and the CLI is a user interface
you need to realize that if you pretend to build a operating system the goal using a operating system for users is to build their work on top of that and not play around with the operating system all the time by looking which things are replaced or got a new syntax
2014-06-11 17:20 GMT+02:00 Jan Zelený jzeleny@redhat.com:
Also, dnf
needs to drop all the legacy options before the transition (ie) pick
erase
or remove (preferably the latter) etc rather than retain all the compatibility options.
The transition period is one reason why we want to keep the name dnf.
The compatibility options can be kept in /usr/bin/yum without cluttering up /usr/bin/dnf.
Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations.
That’s a pure illusion. The users have a compatibility expectation that *their software will continue working*. Compared to asking the users to notice and work around removal of “obsoleted stuff” in /usr/bin/yum, asking the users to notice and work around removal of “obsoleted stuff” in /usr/bin/yum *and in addition to change the command name in their scripts* is, AFAICT, just making things worse. Mirek
On 06/11/2014 11:20 AM, Jan Zelený wrote:
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf.
I think this is a mistake---if dns truly provides the functionality then it should replace yum. Hopefully the majority of people can use dnf as is, but if there are corner cases that only the original yum handles, then it's better to make it available as, say, 'yum-original' or 'yum --yum-me-harder'.
It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'.
On 11. 6. 2014 at 15:03:12, Przemek Klosowski wrote:
On 06/11/2014 11:20 AM, Jan Zelený wrote:
The transition period is one reason why we want to keep the name dnf.
We'd
basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf.
I think this is a mistake---if dns truly provides the functionality then it should replace yum. Hopefully the majority of people can use dnf as is, but if there are corner cases that only the original yum handles, then it's better to make it available as, say, 'yum-original' or 'yum --yum-me-harder'.
As I said on numerous occasions during the last few days, dnf is not a 100% drop-in replacement of yum. It aims to be as compatible as possible but within reason - one of the important goals of dnf is clean and maintainable design.
It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'.
As I said, we will have transition layer so using yum in your shell scripts will still work for a few more releases. A vast majority of users should not experience any inconveniences other than different output on the command line.
Thanks Jan
2014-06-12 9:30 GMT+02:00 Jan Zelený jzeleny@redhat.com:
It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'.
As I said, we will have transition layer so using yum in your shell scripts will still work for a few more releases. A vast majority of users should not experience any inconveniences other than different output on the command line.
… *now*, but *will be inconvenienced later* after those “a few more releases” when you are planning for the yum command to go away. The total breakage and total impact on users is the same, you are only arguing for a different timing that makes it seem like a smaller breakage.
(And separately, I don’t buy the argument that this redirection-with-a-message is how users learn about the new tools. This way they only learn about the *most useless* part of the change, namely “that old thing the system used to do? It can do the same thing, but in addition you have to learn a new command to keep it working“. It doesn’t teach *the useful part*, “here are the new features and here’s how to use them" at all.) Mirek
On 12.6.2014 16:16, Miloslav Trmač wrote:
2014-06-12 9:30 GMT+02:00 Jan Zelený jzeleny@redhat.com:
It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'.
As I said, we will have transition layer so using yum in your shell scripts will still work for a few more releases. A vast majority of users should not experience any inconveniences other than different output on the command line.
… *now*, but *will be inconvenienced later* after those “a few more releases” when you are planning for the yum command to go away. The total breakage and total impact on users is the same, you are only arguing for a different timing that makes it seem like a smaller breakage.
(And separately, I don’t buy the argument that this redirection-with-a-message is how users learn about the new tools. This way they only learn about the *most useless* part of the change, namely “that old thing the system used to do? It can do the same thing, but in addition you have to learn a new command to keep it working“. It doesn’t teach *the useful part*, “here are the new features and here’s how to use them" at all.)
I support people who are requesting "yum" name to stay with us forever.
Please replace "yum" with "dnf" when yum-legacy is finally dropped.
On 12. 6. 2014 at 16:16:13, Miloslav Trmač wrote:
2014-06-12 9:30 GMT+02:00 Jan Zelený jzeleny@redhat.com:
It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'.
As I said, we will have transition layer so using yum in your shell scripts will still work for a few more releases. A vast majority of users should not experience any inconveniences other than different output on the
command
line.
… *now*, but *will be inconvenienced later* after those “a few more releases” when you are planning for the yum command to go away. The
total
breakage and total impact on users is the same, you are only arguing for a different timing that makes it seem like a smaller breakage.
I think we are getting way, *way* ahead of ourselves. You are talking about the distant future as if it was to happen tomorrow. If users will want the command to stay here forever, it might as well stay here forever. This should *not* be the topic of the day, as it is currently irrelevant.
(And separately, I don’t buy the argument that this redirection-with-a-message is how users learn about the new tools. This way they only learn about the *most useless* part of the change, namely “that old thing the system used to do? It can do the same thing, but in addition you have to learn a new command to keep it working“. It doesn’t teach *the useful part*, “here are the new features and here’s how to use them" at all.)
For your information, Ales does terrific job getting the knowledge of new features to public. DNF's documentation is one of the best I have ever seen, especially considering that the project is very much WIP. Blog posts are published almost every week, we regularly announce the interesting stuff on f- d-l, f-u-l and yum-devel list. If you have any ideas how to make the situation even better and actually make users care, please do share them with us!
Thanks Jan
Am 13.06.2014 10:13, schrieb Jan Zelený:
On 12. 6. 2014 at 16:16:13, Miloslav Trmač wrote:
… *now*, but *will be inconvenienced later* after those “a few more releases” when you are planning for the yum command to go away. The total breakage and total impact on users is the same, you are only arguing for a different timing that makes it seem like a smaller breakage.
I think we are getting way, *way* ahead of ourselves. You are talking about the distant future as if it was to happen tomorrow. If users will want the command to stay here forever, it might as well stay here forever. This should *not* be the topic of the day, as it is currently irrelevant
smart decisions are made by think about the distant future to prevent mistakes and excuses like "if i only had known that i would have..."
Dne 11.6.2014 17:20, Jan Zelený napsal(a):
On 11. 6. 2014 at 09:02:29, Rahul Sundaram wrote:
Hi
On Wed, Jun 11, 2014 at 8:52 AM, Matthew Miller wrote:
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This
also
seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every
time
it is used?
I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except
some
of the command line changes which happened with yum anyway (download
only
was added and later removed for example) and one can warn specifically for those. The API changes are not something users care about. Also, dnf needs to drop all the legacy options before the transition (ie) pick erase or remove (preferably the latter) etc rather than retain all the compatibility options.
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf.
Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations.
Thanks Jan
I, for one, support this change as it was proposed.
Vít
On 06/11/2014 08:20 AM, Jan Zelený wrote:
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations. Thanks Jan
Coming late to the discusssion and reading Richards Hughes blog prompted me to comment.
From my understanding, DNF was supposed to be a temporary name for forked Yum to prevent conflicts with the current version of yum until its full stability. About DNF having a complete different python API from yum, there is an overlooked historical example: GCC (GNU Compiler Collection) and its fork ECGS (Experimental/Enhanced GNU Compiler System) where the latter was in fact renamed GCC with full support of FSF agreeing to drop the original GCC 2.x.
Luya
On 6/17/2014 12:50 PM, Luya Tshimbalanga wrote:
On 06/11/2014 08:20 AM, Jan Zelený wrote:
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations. Thanks Jan
Coming late to the discusssion and reading Richards Hughes blog prompted me to comment.
From my understanding, DNF was supposed to be a temporary name for forked Yum to prevent conflicts with the current version of yum until its full stability. About DNF having a complete different python API from yum, there is an overlooked historical example: GCC (GNU Compiler Collection) and its fork ECGS (Experimental/Enhanced GNU Compiler System) where the latter was in fact renamed GCC with full support of FSF agreeing to drop the original GCC 2.x.
Luya
Excuse me. By now I doubt anyone but the Yum zealots really care. Just do it. Make the switch. The Yum zealots will find something else to complain about later. Perhaps the size of the default font? :-)
Once upon a time, David dgboles@gmail.com said:
Excuse me. By now I doubt anyone but the Yum zealots really care. Just do it. Make the switch. The Yum zealots will find something else to complain about later. Perhaps the size of the default font? :-)
Please do not call people that like command consistency "zealots".
From a system administration point of view, if dnf implements largely
the same common command interface as yum, it would be MUCH better if it the command-line utility continues to be "yum". It was annoying when we went from "up2date" to "yum", but there was good reason (they were not at all CLI-compatible). If the common (aka commonly-scripted) CLI commands are the same, especially "<foo> install <package>" and "<foo> upgrade", it would be much nicer to people that manage dozens or hundreds of servers (where they won't all be upgraded in the same time frame) to NOT arbitrarily change the name.
Am 17.06.2014 19:26, schrieb David:
On 6/17/2014 12:50 PM, Luya Tshimbalanga wrote:
On 06/11/2014 08:20 AM, Jan Zelený wrote:
The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations. Thanks Jan
Coming late to the discusssion and reading Richards Hughes blog prompted me to comment.
From my understanding, DNF was supposed to be a temporary name for forked Yum to prevent conflicts with the current version of yum until its full stability. About DNF having a complete different python API from yum, there is an overlooked historical example: GCC (GNU Compiler Collection) and its fork ECGS (Experimental/Enhanced GNU Compiler System) where the latter was in fact renamed GCC with full support of FSF agreeing to drop the original GCC 2.x.
Excuse me. By now I doubt anyone but the Yum zealots really care. Just do it. Make the switch. The Yum zealots will find something else to complain about later. Perhaps the size of the default font? :-)
before you call others "zealots" you should ask yourself if you are just only a ordinary user with his single machine or have to manage *a lot* of machines, some of them even RHEL5/RHEL6 and want consistency if a break has no good reason except "because we can break what we want"
go out and work professional with IT systems and responsibility and you react completly different to un-needed braks because you have better things to do than "change for the sake of change"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 6/17/2014 1:59 PM, Reindl Harald wrote:
Am 17.06.2014 19:26, schrieb David:
before you call others "zealots" you should ask yourself if you are just only a ordinary user with his single machine or have to manage *a lot* of machines, some of them even RHEL5/RHEL6 and want consistency if a break has no good reason except "because we can break what we want"
You completely missed my point. The Fedora Devs have been working on this. The Fedora Devs want to do this. The Fedora Devs have said that they are going to do this. And when. Which means? You, and others, are going to have to deal with this. Bit*hing day after day does not appear to work here.
go out and work professional with IT systems and responsibility and you react completly different to un-needed braks because you have better things to do than "change for the sake of change"
As for "work professional"? I use computers everyday. 45 years ago when I started in my trade computers did not exist. But they came along and I adapted. Things change. Some of us adapt. Some of us just complain. Over and over.
I know how you are. You have to have the last word. So it it your turn. However this threed just hit /null/void
But you have a lovely day. - --
David
Hi
On Tue, Jun 17, 2014 at 2:11 PM, David wrote:
You completely missed my point. The Fedora Devs have been working on this. The Fedora Devs want to do this. The Fedora Devs have said that they are going to do this. And when. Which means? You, and others, are going to have to deal with this. Bit*hing day after day does not appear to work here.
Features are announced in the list to gather feedback and this is precisely what is being provided. Now, the tone is some of these discussions could certainly be improved but you are not helping it by calling it "Bit*ching" and discouraging people from voicing their concerns. Please don't do that
Rahul
On 6/17/2014 2:17 PM, Rahul Sundaram wrote:
Hi
On Tue, Jun 17, 2014 at 2:11 PM, David wrote:
You completely missed my point. The Fedora Devs have been working on this. The Fedora Devs want to do this. The Fedora Devs have said that they are going to do this. And when. Which means? You, and others, are going to have to deal with this. Bit*hing day after day does not appear to work here.Features are announced in the list to gather feedback and this is precisely what is being provided. Now, the tone is some of these discussions could certainly be improved but you are not helping it by calling it "Bit*ching" and discouraging people from voicing their concerns. Please don't do that
Rahul
Somehow this one made it through the filter. But you are correct. My apologizes to the Devs.
As for the whiners? No.
I'm outa' here.
Am 17.06.2014 20:11, schrieb David:
On 6/17/2014 1:59 PM, Reindl Harald wrote:
Am 17.06.2014 19:26, schrieb David:
before you call others "zealots" you should ask yourself if you are just only a ordinary user with his single machine or have to manage *a lot* of machines, some of them even RHEL5/RHEL6 and want consistency if a break has no good reason except "because we can break what we want"
You completely missed my point. The Fedora Devs have been working on this. The Fedora Devs want to do this. The Fedora Devs have said that they are going to do this. And when. Which means?
you made no point, you just insulted people taking care
You, and others, are going to have to deal with this. Bit*hing day after day does not appear to work here.
shut up all the time and suck any mistake with love also
go out and work professional with IT systems and responsibility and you react completly different to un-needed braks because you have better things to do than "change for the sake of change"
As for "work professional"? I use computers everyday. 45 years ago when I started in my trade computers did not exist. But they came along and I adapted. Things change. Some of us adapt. Some of us just complain. Over and over.
so you are bored and have nothing else to do than suck and adopt? fine for you, but don't call others "zealots"
there are well justified changes and there are worthless ones change for the sake of change is worthless
these "zealots" have other things do, be it to test updates, give feedback, test upstream dev-versions long before they hit Fedora
since they day has only 24 hours waste there time with useless changes means something else has no time left
example? mod_security 2.8 was here in production before the Fedora maintainer even knew that it will be released by working with upstream as well as the fixes for mod_security and / Apache 2.4 / mod_remoteip are tested by me and the latter explained in many hours why they need to be done for the sake of security
everytime somebody bothers me with useless changes to adopt that time is missing for such tasks
On 17 June 2014 19:11, David dgboles@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 6/17/2014 1:59 PM, Reindl Harald wrote:
Am 17.06.2014 19:26, schrieb David:
before you call others "zealots" you should ask yourself if you are just only a ordinary user with his single machine or have to manage *a lot* of machines, some of them even RHEL5/RHEL6 and want consistency if a break has no good reason except "because we can break what we want"
You completely missed my point. The Fedora Devs have been working on this. The Fedora Devs want to do this. The Fedora Devs have said that they are going to do this. And when. Which means? You, and others, are going to have to deal with this.
Or leave. And the more perception there is that things are being done for no other reason than "The Fedora Devs want to do this," the more people will want to go elsewhere.
2014-06-11 15:02 GMT+02:00 Rahul Sundaram metherid@gmail.com:
I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except some of the command line changes which happened with yum anyway (download only was added and later removed for example) and one can warn specifically for those.
Yeah, if the compatibility is there, it should *just be there*. Software is here to server users, so the appropriate thing to do on (yum update) is to update the system, not to use this as an appropriate moment to essentially advertise users about a new project or about our achievements (even though the dnf project *is* an achievement, don’t get me wrong).
It makes sense to only add new features to the (dnf) command, or to warn/fail when the yum compatibility doesn’t actually exist. But when the compatibility exists, the right thing for the users is to just do what was asked, no questions asked.
(Structurally, this would also allow you to separate the compatibility UI hacks in /usr/bin/yum, keeping /usr/bin/dnf a bit more clean.) Mirek
On 11. 6. 2014 at 18:53:36, Miloslav Trmač wrote:
2014-06-11 15:02 GMT+02:00 Rahul Sundaram metherid@gmail.com:
I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command
except some
of the command line changes which happened with yum anyway
(download only
was added and later removed for example) and one can warn specifically
for
those.
Yeah, if the compatibility is there, it should *just be there*. Software is here to server users, so the appropriate thing to do on (yum update) is to update the system, not to use this as an appropriate moment to essentially advertise users about a new project or about our achievements (even though the dnf project *is* an achievement, don’t get me wrong).
It makes sense to only add new features to the (dnf) command, or to warn/fail when the yum compatibility doesn’t actually exist. But when the compatibility exists, the right thing for the users is to just do what was asked, no questions asked.
And indeed it will do what you asked it to do. You will just receive warning that yum is no more and the command should not be used. Again, it's exactly the same what happens when you call service XYZ start and in my opinion it works like a charm. If not for this warning, I'd never learned about systemctl.
(Structurally, this would also allow you to separate the compatibility UI hacks in /usr/bin/yum, keeping /usr/bin/dnf a bit more clean.)
We plan to have /usr/bin/yum as simple as possible. Just print out a warning and redirect to yum, something like that. As I wrote before, if you want it to do anything else, we welcome the patches.
Thanks Jan
On 11. 6. 2014 at 08:52:34, Matthew Miller wrote:
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It
obsoletes
Yum and provides its own <code>/usr/bin/yum</code>, a short script
that
redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed
so
will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf.
As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback.
Thanks Jan
On Wed, Jun 11, 2014 at 05:21:30PM +0200, Jan Zelený wrote:
On 11. 6. 2014 at 08:52:34, Matthew Miller wrote:
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It
obsoletes
Yum and provides its own <code>/usr/bin/yum</code>, a short script
that
redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed
so
will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf.
As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback.
Have puppet, chef, ansible, salt, etc. been taught how to use "dnf" to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message?
Am 11.06.2014 17:37, schrieb Chuck Anderson:
Have puppet, chef, ansible, salt, etc. been taught how to use "dnf" to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message?
because it is not state of the art to change things in a way that the change is not heavily noticed to point out "look we have done something and now it's your turn"
hopefully coreutils will not get a replacement in the next cycle with the commands "move", "copy", "removedir", "Listddir" and obsolete "mv", "cp", "rmdir", "ls"
On 06/11/2014 04:41 PM, Reindl Harald wrote:
Am 11.06.2014 17:37, schrieb Chuck Anderson:
Have puppet, chef, ansible, salt, etc. been taught how to use "dnf" to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message?
because it is not state of the art to change things in a way that the change is not heavily noticed to point out "look we have done something and now it's your turn"
hopefully coreutils will not get a replacement in the next cycle with the commands "move", "copy", "removedir", "Listddir" and obsolete "mv", "cp", "rmdir", "ls"
Good idea, they're clearer. I'll do that in the coming release.
thanks, Pádraig.
Le mercredi 11 juin 2014 à 11:37 -0400, Chuck Anderson a écrit :
On Wed, Jun 11, 2014 at 05:21:30PM +0200, Jan Zelený wrote:
On 11. 6. 2014 at 08:52:34, Matthew Miller wrote:
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It
obsoletes
Yum and provides its own <code>/usr/bin/yum</code>, a short script
that
redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed
so
will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf.
As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback.
Have puppet, chef, ansible, salt, etc. been taught how to use "dnf" to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message?
I would expect puppet/chef to start using the library rather than direct access to the binary.
And for ansible, I think the patch is quite simple, just add 2 lines.
I guess we can start right now to get stuff merged.
On 11. 6. 2014 at 18:09:25, Michael Scherer wrote:
Le mercredi 11 juin 2014 à 11:37 -0400, Chuck Anderson a écrit :
On Wed, Jun 11, 2014 at 05:21:30PM +0200, Jan Zelený wrote:
On 11. 6. 2014 at 08:52:34, Matthew Miller wrote:
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It
obsoletes
Yum and provides its own <code>/usr/bin/yum</code>, a short
script
that
redirects to <code>/usr/bin/dnf</code> with an appropriate
warning
message that DNF is the preferred package manager now. Notice
that
upgrading F21 to F22 will not cause the compat package to be installed
so
will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions.
This
also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the
right
thing, only warning on incompatible usage rather than nagging every time it is used?
Actually the plan is to keep /usr/bin/yum as the primary command
during
the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf.
As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback.
Have puppet, chef, ansible, salt, etc. been taught how to use "dnf" to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message?
I would expect puppet/chef to start using the library rather than direct access to the binary.
And for ansible, I think the patch is quite simple, just add 2 lines.
I guess we can start right now to get stuff merged.
Yes, you can either use dnf's well documented API [1] or you can use the libraries beneath it. That's one of the advantages of dnf. Its individual components were moved to external libraries and can be used by anyone, as few projects can already testify. The last piece that is missing and being worked on is a library wrapping dnf software database.
Thanks Jan
On Wed, Jun 11, 2014 at 11:37:15AM -0400, Chuck Anderson wrote:
Have puppet, chef, ansible, salt, etc. been taught how to use "dnf" to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message?
Even harder to change:
- 10000s of users' brains
- 10000s of pages of web-based documentation and printed books
Just leave the command as "yum" and redirect to dnf transparently.
Rich.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 11 Jun 2014 08:52:34 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It
obsoletes Yum and provides its own <code>/usr/bin/yum</code>, a short script that redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
I have personally always been under the impression that when dnf was ready to be a yum replacement it would all be renamed to yum. though there is still a lof of areas we will have to work on before dnf can be a replacement. I am not away of any work to make mock use dnf. dnf will need to be able to make mock chroots going all the way back to rhel5 since we use mock in the buildsystem and we build epel5 there.
I really think forcing users to use dnf as the command is going to be a lot of needless retraining and redoing of work.
Dennis
On Tue, Jun 17, 2014 at 02:40:45PM -0500, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 11 Jun 2014 08:52:34 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It
obsoletes Yum and provides its own <code>/usr/bin/yum</code>, a short script that redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
I have personally always been under the impression that when dnf was ready to be a yum replacement it would all be renamed to yum. though there is still a lof of areas we will have to work on before dnf can be a replacement. I am not away of any work to make mock use dnf. dnf will need to be able to make mock chroots going all the way back to rhel5 since we use mock in the buildsystem and we build epel5 there.
Wait, why will it need to do that? The chroots appear to be compatible, unless I've missed something major. So creating them with the RHEL 5 host's yum should work, I hope. Is there a something I've missed?
On Tue, 2014-06-17 at 16:37 -0400, Peter Jones wrote:
On Tue, Jun 17, 2014 at 02:40:45PM -0500, Dennis Gilmore wrote:
I am not away of any work to make mock use dnf. dnf will need to be able to make mock chroots going all the way back to rhel5 since we use mock in the buildsystem and we build epel5 there.
Wait, why will it need to do that? The chroots appear to be compatible, unless I've missed something major. So creating them with the RHEL 5 host's yum should work, I hope. Is there a something I've missed?
The host might not be RHEL 5, it could be Fedora 22.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 17 Jun 2014 16:37:32 -0400 Peter Jones pjones@redhat.com wrote:
On Tue, Jun 17, 2014 at 02:40:45PM -0500, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 11 Jun 2014 08:52:34 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote:
- package 'dnf-yum-compat-command' is installed by default. It
obsoletes Yum and provides its own <code>/usr/bin/yum</code>, a short script that redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users.
This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the "yum" name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called "dnf", but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used?
I have personally always been under the impression that when dnf was ready to be a yum replacement it would all be renamed to yum. though there is still a lof of areas we will have to work on before dnf can be a replacement. I am not away of any work to make mock use dnf. dnf will need to be able to make mock chroots going all the way back to rhel5 since we use mock in the buildsystem and we build epel5 there.
Wait, why will it need to do that? The chroots appear to be compatible, unless I've missed something major. So creating them with the RHEL 5 host's yum should work, I hope. Is there a something I've missed?
i am talking about creating a rhel5 chroot on Fedora 21. not saying it wont work. but we need to ensure that it givces us the same results, same for el6, el7 should just be fine. it may just work, but it needs explicit testing.
Dennis
On 06/17/2014 09:40 PM, Dennis Gilmore wrote:
I am not away of any work to make mock use dnf.
As part of GSoC Michael Simacek is working on improving mock. Among other features, DNF support is already implemented and working. More information can be found on his blog [1] (part of Fedora Planet).
The code is hosted on [2], RPMs for latest development version can be found on Fedora Jenkins [3] (the RPM is renamed to xmock to allow parallel installation with mock from Fedora repos).
[1] http://xpath-of-light.blogspot.cz/ [2] http://github.com/msimacek/mock [3] http://jenkins.cloud.fedoraproject.org/job/mock/ws/RPMS/
On Wed, Jun 11, 2014 at 2:44 PM, Jaroslav Reznik jreznik@redhat.com wrote:
= Proposed System Wide Change: Replace Yum With DNF = https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
Note: This is Fedora 22 proposal!
Change owner(s): Aleš Kozumplík kozumplik@gmail.com
Make DNF/Yum4 the new default packaging tool in F22.
== Detailed Description == DNF was forked from Yum in January 2012 and available for experimenting in Fedora since release 18 [1]. The project is now fully capable of replacing Yum in new Fedora installations. We want DNF to become the new default packaging tool in Fedora 22. This entails:
- letting system administrators (including users who routinely manage their
packages using the legacy Yum) perform all common packaging operations using DNF, with no or minimal and documented [2] change to the command syntax, apart from replacing the command name. (done)
- providing implementation of Anaconda backend so system can be bootstrapped
completely without using legacy Yum. (done)
- providing alternative to all Yum plugins from yum-utils (ongoing)
- providing alternative to all release engineering tools (repoquery, bodhi
etc.) from yum-utils (ongoing)
- being ready/having the capacity to help out users with migration of their
custom legacy plugins and extensions to DNF. The solid API documentation [3] we provide is of great advantage here. (ongoing)
In practice, the change implies:
- Anaconda installs the system using the DNF backend (with no special
switches)
- package 'dnf' is installed by default (referenced by the base comps groups)
- package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum
and provides its own <code>/usr/bin/yum</code>, a short script that redirects to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users.
That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one.
We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad.... also why maybe his biggest yum was not his only contribution.
Am 11.06.2014 16:08, schrieb drago01:
We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad.... also why maybe his biggest yum was not his only contribution
if it obsoletes and replaces yum it has to provide /usr/bin/yum
because one of the reasons Linux is not that widely used is because you have all the time replace and rewrite things while a smart upstream could avoid that by just place symlinks or not break compatibility for the sake of changes
and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23
On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 11.06.2014 16:08, schrieb drago01:
We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad.... also why maybe his biggest yum was not his only contribution
if it obsoletes and replaces yum it has to provide /usr/bin/yum
That's what I have said (just with the "if").
[...] and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23
No I disagree here. We already have (and are still in) a "optional to test for user" and it gets active testing. Its time to flip the switch.
Am 11.06.2014 16:20, schrieb drago01:
On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 11.06.2014 16:08, schrieb drago01:
We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad.... also why maybe his biggest yum was not his only contribution
if it obsoletes and replaces yum it has to provide /usr/bin/yum
That's what I have said (just with the "if").
[...] and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23
No I disagree here. We already have (and are still in) a "optional to test for user" and it gets active testing. Its time to flip the switch
well, that's something different than have on a new setup DNF instead YUM and if things are working properly you don't notice, make a reality check: the way a optin-user tests and classifies things are completly different as a random user not knowing about the replacement
if sensible core components are replaced there should be a way back in case of troubles and not a dry "there where testers live with it"
those testers until now maybe not represent the relevant usecases
if i replace software i do it always in steps and that is why i did not breaks cumstomers setups the last 11 years:
* internal tests * asking some representative users for testing * update a picked set of users without saying anything * if they report troubles try to fix them within 2 up to 5 hours * if that's not possible revert the change for them * try to fix the problem without angry users * roll it out again for the picked set * and then roll it out for everybody * and even in that last step there must exist a way back
the golden rule for accepted big changes is *never* break users setup and never make a abusive change with no way back and leave only telling him he has to chew and adopt
On Wed, Jun 11, 2014 at 4:30 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 11.06.2014 16:20, schrieb drago01:
On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 11.06.2014 16:08, schrieb drago01:
We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad.... also why maybe his biggest yum was not his only contribution
if it obsoletes and replaces yum it has to provide /usr/bin/yum
That's what I have said (just with the "if").
[...] and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23
No I disagree here. We already have (and are still in) a "optional to test for user" and it gets active testing. Its time to flip the switch
well, that's something different than have on a new setup DNF instead YUM and if things are working properly you don't notice, make a reality check: the way a optin-user tests and classifies things are completly different as a random user not knowing about the replacement
if sensible core components are replaced there should be a way back in case of troubles and not a dry "there where testers live with it"
those testers until now maybe not represent the relevant usecases
if i replace software i do it always in steps and that is why i did not breaks cumstomers setups the last 11 years:
- internal tests
- asking some representative users for testing
- update a picked set of users without saying anything
- if they report troubles try to fix them within 2 up to 5 hours
- if that's not possible revert the change for them
- try to fix the problem without angry users
- roll it out again for the picked set
- and then roll it out for everybody
- and even in that last step there must exist a way back
the golden rule for accepted big changes is *never* break users setup and never make a abusive change with no way back and leave only telling him he has to chew and adopt
Sure but that should also applies to upgrades (i.e do not just upgrade on productive systems without prior testing on a replicated test environment; which you probably do anyway).
I am not really opposed to having "a way back" if it is opt in and not simply split the userbase based on how the system got installed (this is a mess to support comparing to having a handful of users that opted to "go back"). Support aside at least the workstation prd states that upgrades should not have a worse expirence then new installs having a slower depsolver / package installer would fall into that.
On Wed, Jun 11, 2014 at 04:08:09PM +0200, drago01 wrote:
We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad.... also why maybe his biggest yum was not his only contribution.
Oh, of course not. I just think it would be a nice (and respectful) thing to do. (I do notice that the feature page mentions "yum 4", which I assume is a consideration of this approach.)
2014-06-11 16:08 GMT+02:00 drago01 drago01@gmail.com:
That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one.
Precisely; such splits are always incredibly painful for everyone.
Yes, it would require a more detailed contingency planning, but having upgraded and new systems use a different package manager by the same command name and the same scripts would be a troubleshooting nightmare. Mirek
On 11. 6. 2014 at 18:55:37, Miloslav Trmač wrote:
2014-06-11 16:08 GMT+02:00 drago01 drago01@gmail.com:
That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one.
Precisely; such splits are always incredibly painful for everyone.
Yes, it would require a more detailed contingency planning, but having upgraded and new systems use a different package manager by the same command name and the same scripts would be a troubleshooting nightmare.
We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders.
Thanks Jan
On Thu, Jun 12, 2014 at 10:03 AM, Jan Zelený jzeleny@redhat.com wrote:
On 11. 6. 2014 at 18:55:37, Miloslav Trmač wrote:
2014-06-11 16:08 GMT+02:00 drago01 drago01@gmail.com:
That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one.
Precisely; such splits are always incredibly painful for everyone.
Yes, it would require a more detailed contingency planning, but having upgraded and new systems use a different package manager by the same command name and the same scripts would be a troubleshooting nightmare.
We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders.
Well having user that upgrade have a different package manager then those who install new is not only "not perfect" but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand.
We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders.
Well having user that upgrade have a different package manager then those who install new is not only "not perfect" but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand.
I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot.
Thanks Jan
On Thu, Jun 12, 2014 at 02:10:22PM +0200, Jan Zelený wrote:
We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders.
Well having user that upgrade have a different package manager then those who install new is not only "not perfect" but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand.
I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot.
The arguments against renaming the command have been given. The dnf command should either be renamed back to yum, or there should be permanent backwards compatibility via a script, symlink, etc. There is NO good reason to force everyone to change scripts and command line habits just for the sake of changing the name of a command that is an almost 100% compatible evolution of the older command. Call the package dnf and obsolete the yum package, rename the old yum package to yum-legacy--fine. But please make "yum install" etc. still work with dnf.
And if those arguments aren't convincing enough, the second best option, if you MUST change the name of the command, is to change it ONCE to something PERMANENT that never changes ever again. Something generic like "package-manager" or "pkgman". A name like "dnf" isn't really helpful as part of the system command language "API". It is obscure lore that contributes to making Linux harder to learn. (So is "yum" but that ship has sailed.)
On Čt, 2014-06-12 at 10:09 -0400, Chuck Anderson wrote:
On Thu, Jun 12, 2014 at 02:10:22PM +0200, Jan Zelený wrote:
We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders.
Well having user that upgrade have a different package manager then those who install new is not only "not perfect" but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand.
I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot.
The arguments against renaming the command have been given. The dnf command should either be renamed back to yum, or there should be permanent backwards compatibility via a script, symlink, etc. There is NO good reason to force everyone to change scripts and command line habits just for the sake of changing the name of a command that is an almost 100% compatible evolution of the older command. Call the package dnf and obsolete the yum package, rename the old yum package to yum-legacy--fine. But please make "yum install" etc. still work with dnf.
And if those arguments aren't convincing enough, the second best option, if you MUST change the name of the command, is to change it ONCE to something PERMANENT that never changes ever again. Something generic like "package-manager" or "pkgman". A name like "dnf" isn't really helpful as part of the system command language "API". It is obscure lore that contributes to making Linux harder to learn. (So is "yum" but that ship has sailed.)
BTW repoquery --repoid=rawhide -f /usr/bin/pkg gives empty output so if you are really really sure that the command must be renamed, please use 'pkg'.
But I vote for keeping yum symlink or script wrapper forever.
On 12. 6. 2014 at 10:09:13, Chuck Anderson wrote:
On Thu, Jun 12, 2014 at 02:10:22PM +0200, Jan Zelený wrote:
We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders.
Well having user that upgrade have a different package manager then those who install new is not only "not perfect" but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users
that
want it for whatever reason install it by hand.
I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot.
The arguments against renaming the command have been given. The dnf command should either be renamed back to yum, or there should be permanent backwards compatibility via a script, symlink, etc. There is NO good reason to force everyone to change scripts and command line habits just for the sake of changing the name of a command that is an almost 100% compatible evolution of the older command. Call the package dnf and obsolete the yum package, rename the old yum package to yum-legacy--fine. But please make "yum install" etc. still work with dnf.
We are on the same page, thanks for your input.
Jan
Hi
On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote:
We are on the same page, thanks for your input.
I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user. The analogy to systemctl doesn't work because systemctl is part of a completely separate project that works very differently from service command while dnf is a experimental fork of yum with a few fairly minor differences in command line and configuration options.
Rahul
I am +1 for keeping the 'yum' name for the new manager, if only for the connotation.
Telling users/consumers/customers that yum is upgraded and awesome is much easier than telling them that yum has been replaced and that the new tool is awesome. Even something like 'yum4' would be preferable to a new acronym to learn.
Thanks,
Jamie Duncan, RHCE Senior Technical Account Manager Red Hat, Inc.
jduncan@redhat.com
w-804.343.6086 c-804.307.7079 tech support-888.GO.REDHAT
----- Original Message -----
From: "Rahul Sundaram" metherid@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Thursday, June 12, 2014 11:03:35 AM Subject: Re: F22 System Wide Change: Replace Yum With DNF
Hi
On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote:
We are on the same page, thanks for your input.
I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user. The analogy to systemctl doesn't work because systemctl is part of a completely separate project that works very differently from service command while dnf is a experimental fork of yum with a few fairly minor differences in command line and configuration options.
Rahul
2014-06-12 17:03 GMT+02:00 Rahul Sundaram metherid@gmail.com:
On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote:
We are on the same page, thanks for your input.
I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user.
There are not only two sides :) I don’t insist on dnf being a hidden “internal project name”; introducing new features (only?) under the dnf name is fine with me. I do object to planning to unnecessarily break the yum commands for which we actually have compatibility. Mirek
On Thu, 2014-06-12 at 17:13 +0200, Miloslav Trmač wrote:
2014-06-12 17:03 GMT+02:00 Rahul Sundaram metherid@gmail.com:
On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote:
We are on the same page, thanks for your input.
I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user.
There are not only two sides :) I don’t insist on dnf being a hidden “internal project name”; introducing new features (only?) under the dnf name is fine with me. I do object to planning to unnecessarily break the yum commands for which we actually have compatibility.
We can keep the yum symlink forever...
I am for a clear break with dnf having its own name. Using yum as the name for dnf is just a lie to the user and is not helpful. Dnf is a completely different project and code base that just happens to be highly compatible with yum as a way to smooth the transition. That is perfectly fine, and not spreading lies is an excellent strategy to slowly educate users.
The service -> systemctl example is actually an excellent example of a smooth transition IMO, and should be followed.
If you like yum you keep the compat package, if you hate it: dnf remove yum-compat and be happy.
Simo.
Am 12.06.2014 17:41, schrieb Simo Sorce:
We can keep the yum symlink forever...
I am for a clear break with dnf having its own name. Using yum as the name for dnf is just a lie to the user
it is not a lie
DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM
as said: otherwise you would have to find a new name for any major version with large changes of any piece of software (GNOME, KDE, Apache....)
frankly and as long there is no useful name call something "DNF" is not helpful because it has no meaning while YUM is widely known as
* yet another update manager * yellowdog updater modified
On Thu, 2014-06-12 at 17:54 +0200, Reindl Harald wrote:
Am 12.06.2014 17:41, schrieb Simo Sorce:
We can keep the yum symlink forever...
I am for a clear break with dnf having its own name. Using yum as the name for dnf is just a lie to the user
it is not a lie
DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM
as said: otherwise you would have to find a new name for any major version with large changes of any piece of software (GNOME, KDE, Apache....)
frankly and as long there is no useful name call something "DNF" is not helpful because it has no meaning while YUM is widely known as
- yet another update manager
- yellowdog updater modified
I think that dnf is an unfortunate name change. DNF in almost all kinds of racing stands for Did Not Finish....
Regards, Les H
On 12 June 2014 16:54, Reindl Harald h.reindl@thelounge.net wrote:
DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM
Just do a side-by-side comparison of the code bases. Calling dnf "yum" would be a lie indeed.
Richard.
Am 13.06.2014 10:15, schrieb Richard Hughes:
On 12 June 2014 16:54, Reindl Harald h.reindl@thelounge.net wrote:
DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM
Just do a side-by-side comparison of the code bases. Calling dnf "yum" would be a lie indeed
and why do you call GNOME3 then GNOME?
On Fri, Jun 13, 2014 at 10:16:41AM +0200, Reindl Harald wrote:
Am 13.06.2014 10:15, schrieb Richard Hughes:
On 12 June 2014 16:54, Reindl Harald h.reindl@thelounge.net wrote:
DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM
Just do a side-by-side comparison of the code bases. Calling dnf "yum" would be a lie indeed
and why do you call GNOME3 then GNOME?
Ehr? Most modules are pretty much the same. Code wise, not that many changes. New module called gnome-shell and the looks greatly changed. Code wise? Not so much.
On Fri, 13 Jun 2014 09:15:11 +0100, Richard Hughes wrote:
On 12 June 2014 16:54, Reindl Harald h.reindl@thelounge.net wrote:
DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM
Just do a side-by-side comparison of the code bases. Calling dnf "yum" would be a lie indeed.
I think your missing the point. yum is what we use to update/install/remove/etc packages, whether it's yum yum or yum dnf, yum is what we use.
On 12. 6. 2014 at 11:41:52, Simo Sorce wrote:
On Thu, 2014-06-12 at 17:13 +0200, Miloslav Trmač wrote:
2014-06-12 17:03 GMT+02:00 Rahul Sundaram metherid@gmail.com:
On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote:
We are on the same page, thanks for your input.
I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command.
The
other side is wanting yum to continue to remain the name for the
command
with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user.
There are not only two sides :) I don’t insist on dnf being a hidden “internal project name”; introducing new features (only?) under the dnf name is fine with me. I do object to planning to unnecessarily break the yum commands for which we actually have compatibility.
We can keep the yum symlink forever...
Definitely, we do no insist on removing it. I am perfectly fine with removing it some time far in the future when nobody uses it any more.
Thanks Jan
Am 13.06.2014 10:01, schrieb Jan Zelený:
On 12. 6. 2014 at 11:41:52, Simo Sorce wrote:
We can keep the yum symlink forever...
Definitely, we do no insist on removing it. I am perfectly fine with removing it some time far in the future when nobody uses it any more
one said "forever", i am not a native english speaker but IMHO that word has a clear definition
* do not insist on removing it * removing it some time far in the future
you can have one of them :-)
i have not heard any valid reason to call a software DNF instead just the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to "Did Not Finish" beause it has no senseful meaning and so finally you can call it "yum-ng" and in the history ng-replacements did not change binary names
On 13. 6. 2014 at 10:09:48, Reindl Harald wrote:
Am 13.06.2014 10:01, schrieb Jan Zelený:
On 12. 6. 2014 at 11:41:52, Simo Sorce wrote:
We can keep the yum symlink forever...
Definitely, we do no insist on removing it. I am perfectly fine with removing it some time far in the future when nobody uses it any more
one said "forever", i am not a native english speaker but IMHO that word has a clear definition
- do not insist on removing it
- removing it some time far in the future
you can have one of them :-)
Please, don't nitpick, it's not cool. What I meant is to maybe remove it when there is a general consensus it should be removed. Period, end of story.
i have not heard any valid reason to call a software DNF instead just the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to "Did Not Finish" beause it has no senseful meaning and so finally you can call it "yum-ng" and in the history ng-replacements did not change binary names
I have explained the reason on multiple occasions. If you volunteer to do the bug cleanup regularly and to explain users on daily basis that dnf is actually different from yum and they should not consider changes in behavior regressions, I will think about this some more (no promises). But fair warning, this effort will cost you about an hour of your time every single day.
This is the last reply to you on this matter, thanks for understanding.
Thanks Jan
2014-06-13 10:20 GMT+02:00 Jan Zelený jzeleny@redhat.com:
On 13. 6. 2014 at 10:09:48, Reindl Harald wrote:
Am 13.06.2014 10:01, schrieb Jan Zelený:
i have not heard any valid reason to call a software DNF instead just
the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to "Did Not Finish" beause it has no senseful meaning and so finally you can call it "yum-ng" and in the history ng-replacements did not change binary names
I have explained the reason on multiple occasions. If you volunteer to do the bug cleanup regularly and to explain users on daily basis that dnf is actually different from yum and they should not consider changes in behavior regressions, I will think about this some more (no promises). But fair warning, this effort will cost you about an hour of your time every single day.
So not wanting users to complain about “yum” no longer having some features is the only reason for dropping the yum name I have seen in this thread (also called “setting expectations”); have I missed other reasons?
If this is *the* reason, and you simultaneously propose to *keep* the “yum” name for the forseeable future, i.e. for the *entire time users are likely to complain*, how do you expect to get the benefit? AFAICS those bugs will get filed and will have to be handled, so “setting expectations” will not help your team’s workload at all.
What am I missing? Mirek
On 13. 6. 2014 at 11:36:25, Miloslav Trmač wrote:
2014-06-13 10:20 GMT+02:00 Jan Zelený jzeleny@redhat.com:
On 13. 6. 2014 at 10:09:48, Reindl Harald wrote:
Am 13.06.2014 10:01, schrieb Jan Zelený:
i have not heard any valid reason to call a software DNF instead just
the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to "Did Not Finish" beause it has no senseful meaning and so finally you can call it "yum-ng" and in the history ng-replacements did not change binary names
I have explained the reason on multiple occasions. If you volunteer to do the bug cleanup regularly and to explain users on daily basis that dnf is actually different from yum and they should not consider changes in behavior regressions, I will think about this some more (no promises). But fair warning, this effort will cost you about an hour of your time every single day.
So not wanting users to complain about “yum” no longer having some
features
is the only reason for dropping the yum name I have seen in this thread (also called “setting expectations”); have I missed other reasons?
No, there is not. But I think you misunderstood the reason, although not by much. The fact is that dnf *is* different project than yum, let's not try to mask it. The vast majority of code base is different (> 85% for sure), its architecture is different, the community is different, the entire nature of the project is different. And the fact that its CLI interface tries to be as compatible as possible with yum doesn't change any of this.
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
If you want some more reasons, consider that the Python API might be different in dnf compared to yum and the configuration is definitely different:
$ man yum.conf | wc -l 872 $ man dnf.conf | wc -l 138
If this is *the* reason, and you simultaneously propose to *keep* the
“yum”
name for the forseeable future, i.e. for the *entire time users are likely to complain*, how do you expect to get the benefit? AFAICS those bugs will get filed and will have to be handled, so “setting expectations” will not help your team’s workload at all.
I wonder now, would it be better if we just dropped the yum command entirely?
Thanks Jan
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
why do so many developers not understand that simple fact?
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
Horses worked too but at some point we decided that cars work better and moved on.
Am 13.06.2014 15:03, schrieb drago01:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
close your eyes for 2 seconds to face how that bothers the user which is the bigot justification for the rename
do you seriously explain me it's wrong that Linux still is called Linux or even that the implementation of 3.15 has anything common with Linux 1.0?
Horses worked too but at some point we decided that cars work better and moved on
that's childish
a horse and a car are completly different things yum and dnf are not
On Fri, 2014-06-13 at 15:15 +0200, Reindl Harald wrote:
Am 13.06.2014 15:03, schrieb drago01:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
close your eyes for 2 seconds to face how that bothers the user which is the bigot justification for the rename
do you seriously explain me it's wrong that Linux still is called Linux or even that the implementation of 3.15 has anything common with Linux 1.0?
Horses worked too but at some point we decided that cars work better and moved on
that's childish
a horse and a car are completly different things yum and dnf are not
I think you are failing to undertstand the concept of "perspective".
The example is actually perfectly fitting.
Why do you care if your "transport" is a horse or a car ? You should just call it "tranmsport", right ?
Anyway I think we should stop with this bikeshedding. The people write the code decided to call it DNF, and it is their right to do so, it is their project and they decided they want a new identity to go with it.
To help the transition they are making it so that if you call "yum" it still works, and this should keep old cranky users happy. Be happy like that.
Simo.
Hi
On Fri, Jun 13, 2014 at 9:33 AM, Simo Sorce <wrote:
I think you are failing to understand the concept of "perspective".
I think there is a difference in perspectives rather than lack of understanding. You are looking at it from a developer perspective - their project, let them do whatever they like but changing the name of a package manager is a extremely intrusive change for all users and commercially supported customers of RHEL down the line and the ripple effects are enormous. We are talking about a ton of documentation that needs to be updated etc. This change shouldn't be done without very careful deliberation and substantial justification. The API changes or code being rewritten isn't something that users care about at all. Some options being changed MAY cause some bug reports isn't enough of a reason to do this IMO. The notion that such bug reports will consume one hour every day for the development team is just a wild speculation. FWIW, I will volunteer to explain to users that this is a different project that choose to use the same name in all such bug reports. Please feel free to reassign them to me.
Regards Rahul
On 06/13/2014 09:03 AM, drago01 wrote:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
Horses worked too but at some point we decided that cars work better and moved on.
Yes but who is this better for? A few developers or the mass of people and documentation that are used to using "yum".
With cars it was obviously better for me - dnf not so obvious.
Regards, Steve
Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit :
On 06/13/2014 09:03 AM, drago01 wrote:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
Horses worked too but at some point we decided that cars work better and moved on.
Yes but who is this better for? A few developers or the mass of people and documentation that are used to using "yum".
With cars it was obviously better for me - dnf not so obvious.
So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it.
But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it.
Am 14.06.2014 02:59, schrieb Michael Scherer:
Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit :
On 06/13/2014 09:03 AM, drago01 wrote:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
Horses worked too but at some point we decided that cars work better and moved on.
Yes but who is this better for? A few developers or the mass of people and documentation that are used to using "yum".
With cars it was obviously better for me - dnf not so obvious.
So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it.
But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it
what are you talking about? *nobody* asked that *nobody*
the point is *not* break YUM as name and in documentations as well as thousands of howtos, articles and books you can't re-write and gain the missing pieces of compatibility
Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit :
Am 14.06.2014 02:59, schrieb Michael Scherer:
Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit :
On 06/13/2014 09:03 AM, drago01 wrote:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
Horses worked too but at some point we decided that cars work better and moved on.
Yes but who is this better for? A few developers or the mass of people and documentation that are used to using "yum".
With cars it was obviously better for me - dnf not so obvious.
So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it.
But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it
what are you talking about? *nobody* asked that *nobody*
Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed.
If you tell me "nothing should be removed forever", then you ask to keep yum forever. If not, then tell what can be removed and when, and others do the same.
the point is *not* break YUM as name and in documentations as well as thousands of howtos, articles and books you can't re-write and gain the missing pieces of compatibility
So ok, let the yum name being used by yum code, cause you want to keep how to running ( ie, that mean understand all options and everything like command line ), and that's it. DNS is DNF, and yum is what you have now, since any option change would result into broken howtos.
Again, tell what can be removed and/or changed.
Am 14.06.2014 03:10, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit :
Am 14.06.2014 02:59, schrieb Michael Scherer:
Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit :
On 06/13/2014 09:03 AM, drago01 wrote:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený: > That being said, the reason for not renaming dnf to yum is that renaming this > project to yum will do nothing else than to confuse its users, as they will > think this is still yum and they should expect from dnf it what they expected > from yum. They should not. And dnf is not yum, I'm really sorry if you think > it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
Horses worked too but at some point we decided that cars work better and moved on.
Yes but who is this better for? A few developers or the mass of people and documentation that are used to using "yum".
With cars it was obviously better for me - dnf not so obvious.
So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it.
But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it
what are you talking about? *nobody* asked that *nobody*
Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed
why do functions and options need to be removed due a code-rewrite/re-factoring? to clean up the code base?
if someone takes the word "improve" in his mouth i don't see a place for "remove" in the same context
the "dirty codebase grown" that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it
that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users
a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces
throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution
Le samedi 14 juin 2014 à 03:20 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:10, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit :
Am 14.06.2014 02:59, schrieb Michael Scherer:
Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit :
On 06/13/2014 09:03 AM, drago01 wrote:
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.reindl@thelounge.net wrote: > Am 13.06.2014 14:53, schrieb Jan Zelený: >> That being said, the reason for not renaming dnf to yum is that renaming this >> project to yum will do nothing else than to confuse its users, as they will >> think this is still yum and they should expect from dnf it what they expected >> from yum. They should not. And dnf is not yum, I'm really sorry if you think >> it is. > the user expects that anyways if you replace something he > did not asked for replace it and what just worked for him Well there are different levels of "works" i.e just because something works that something does not have to be the best possible implementation of "something" ...
Horses worked too but at some point we decided that cars work better and moved on.
Yes but who is this better for? A few developers or the mass of people and documentation that are used to using "yum".
With cars it was obviously better for me - dnf not so obvious.
So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it.
But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it
what are you talking about? *nobody* asked that *nobody*
Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed
why do functions and options need to be removed due a code-rewrite/re-factoring? to clean up the code base?
likely yes. Also because the more code you have, the more corner case you can face, the more time you spend on testing, reimplementing, etc, etc. the dnf developers did a very good job engaging the users to know what matter to them, to integrate likely better or more flexible solution, etc.
Everybody I know who looked at the yum python api told me it was a bit horrible. So a cleanup was needed for that. There was demand from packagekit developers to have a cleaner API as well, and I would hope that tools like puppet/ansible would benefit as well.
And since that's python, you also have the need to be python 3 compatible, which is a rather big task, as seen by the slow migration of the rest of the platform.
The less code you have to port, the less time it take (same goes for testing, documenting, translating)
if someone takes the word "improve" in his mouth i don't see a place for "remove" in the same context
the "dirty codebase grown" that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it
that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users
In fact, since developers can fix bug more easily with a code that is clean, it benefits to users as well.
a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces
Perfect, so are you leading the way, or do you continue to tell to people how to make a smart rewrite without being more specific and without putting any efforts ?
throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution
You still didn't answer to the question I asked. How long do you want compatibility be kept, and what compatibility exactly ?
(remember, you said that no one want to have "everything" "forever", so let's be precise on what you want)
And you can hardly complain to not be listened if you do not answer to precise questions when someone is willing to listen and try to find a solution.
Am 14.06.2014 03:36, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:20 +0200, Reindl Harald a écrit :
why do functions and options need to be removed due a code-rewrite/re-factoring? to clean up the code base?
likely yes. Also because the more code you have, the more corner case you can face, the more time you spend on testing, reimplementing, etc, etc. the dnf developers did a very good job engaging the users to know what matter to them, to integrate likely better or more flexible solution, etc.
maybe in the meantime
i remember bugreports for "keepcache" at the begin of this year which where closed with "WONTFIX" as well as "no we don't protect the OS by allow 'dnf remove kernel dnf'" while "yum -y remove kernel" don#t touch the running one
Everybody I know who looked at the yum python api told me it was a bit horrible. So a cleanup was needed for that. There was demand from packagekit developers to have a cleaner API as well, and I would hope that tools like puppet/ansible would benefit as well.
And since that's python, you also have the need to be python 3 compatible, which is a rather big task, as seen by the slow migration of the rest of the platform.
The less code you have to port, the less time it take (same goes for testing, documenting, translating)
the internal API is between developers the options and CLI params are for users
different worlds
if someone takes the word "improve" in his mouth i don't see a place for "remove" in the same context
the "dirty codebase grown" that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it
that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users
In fact, since developers can fix bug more easily with a code that is clean, it benefits to users as well.
you ignore the bugs of missing functions which will be the first so you postponed the work only
clean != stripped functionality
a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces
Perfect, so are you leading the way, or do you continue to tell to people how to make a smart rewrite without being more specific and without putting any efforts?
my effort is try to prevent thousands of bugreports
did you realize that in this thread it was even suggested to completly remove the yum command over the long even if it is only a symlink?
that is not what that page below previously said, that statet very clear that DNF is a temporary name of the next YUM major version what finally means for any user reading this page it will later called YUM, the technology behind the scenes will be more mordern and that's it from the users perspective
http://fedoraproject.org/wiki/Features/DNF Preview the next-generation Yum package manager, using hawkey/libsolv for backend Note about the name "DNF": it has no relevant meaning, meant as a project name only. Since DNF is a tech preview in Fedora 18 the Python module names can not be 'yum.*' as that would clash with yum itself
throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution
You still didn't answer to the question I asked. How long do you want compatibility be kept, and what compatibility exactly ?
yum-plugin-protectbase yum-plugin-tsflags yum-utils
Loaded plugins: etckeeper, protectbase, tsflags Usage: yum [options] COMMAND
List of Commands:
autoremove Remove leaf packages check Check for problems in the rpmdb check-update Check for available package updates clean Remove cached data deplist List a package's dependencies distribution-synchronization Synchronize installed packages to the latest available versions downgrade downgrade a package erase Remove a package or packages from your system fs Acts on the filesystem data of the host, mainly for removing docs/lanuages for minimal hosts. fssnapshot Creates filesystem snapshots, or lists/deletes current snapshots. groups Display, or use, the groups information help Display a helpful usage message history Display, or use, the transaction history info Display details about a package or group of packages install Install a package or packages on your system list List a package or groups of packages load-transaction load a saved transaction from filename makecache Generate the metadata cache provides Find what package provides the given value reinstall reinstall a package repo-pkgs Treat a repo. as a group of packages, so we can install/remove all of them repolist Display the configured software repositories search Search package details for the given string shell Run an interactive yum shell swap Simple way to swap packages, instead of using shell update Update a package or packages on your system update-minimal Works like upgrade, but goes to the 'newest' package match which fixes a problem that affects your system updateinfo Acts on repository update information upgrade Update packages taking obsoletes into account version Display a version for the machine and/or available repos.
Options: -h, --help show this help message and exit -t, --tolerant be tolerant of errors -C, --cacheonly run entirely from system cache, don't update cache -c [config file], --config=[config file] config file location -R [minutes], --randomwait=[minutes] maximum command wait time -d [debug level], --debuglevel=[debug level] debugging output level --showduplicates show duplicates, in repos, in list/search commands -e [error level], --errorlevel=[error level] error output level --rpmverbosity=[debug level name] debugging output level for rpm -q, --quiet quiet operation -v, --verbose verbose operation -y, --assumeyes answer yes for all questions --assumeno answer no for all questions --version show Yum version and exit --installroot=[path] set install root --enablerepo=[repo] enable one or more repositories (wildcards allowed) --disablerepo=[repo] disable one or more repositories (wildcards allowed) -x [package], --exclude=[package] exclude package(s) by name or glob --disableexcludes=[repo] disable exclude from main, for a repo or for everything --disableincludes=[repo] disable includepkgs for a repo or for everything --obsoletes enable obsoletes processing during updates --noplugins disable Yum plugins --nogpgcheck disable gpg signature checking --disableplugin=[plugin] disable plugins by name --enableplugin=[plugin] enable plugins by name --skip-broken skip packages with depsolving problems --color=COLOR control whether color is used --releasever=RELEASEVER set value of $releasever in yum config and repo files --downloadonly don't update, just download --downloaddir=DLDIR specifies an alternate directory to store packages --setopt=SETOPTS set arbitrary config and repo options --bugfix Include bugfix relevant packages, in updates --security Include security relevant packages, in updates --advisory=ADVS, --advisories=ADVS Include packages needed to fix the given advisory, in updates --bzs=BZS Include packages needed to fix the given BZ, in updates --cves=CVES Include packages needed to fix the given CVE, in updates --sec-severity=SEVS, --secseverity=SEVS Include security relevant packages matching the severity, in updates --tsflags=TSFLAGS
Plugin Options:
(remember, you said that no one want to have "everything" "forever", so let's be precise on what you want)
no - i said no one wants the old yum maintained forever which you claimed that people did
And you can hardly complain to not be listened if you do not answer to precise questions when someone is willing to listen and try to find a solution
http://fedoraproject.org/wiki/Features/DNF Preview the next-generation Yum package manager, using hawkey/libsolv for backend Note about the name "DNF": it has no relevant meaning, meant as a project name only. Since DNF is a tech preview in Fedora 18 the Python module names can not be 'yum.*' as that would clash with yum itself
Le samedi 14 juin 2014 à 03:55 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:36, schrieb Michael Scherer:
Everybody I know who looked at the yum python api told me it was a bit horrible. So a cleanup was needed for that. There was demand from packagekit developers to have a cleaner API as well, and I would hope that tools like puppet/ansible would benefit as well.
And since that's python, you also have the need to be python 3 compatible, which is a rather big task, as seen by the slow migration of the rest of the platform.
The less code you have to port, the less time it take (same goes for testing, documenting, translating)
the internal API is between developers the options and CLI params are for users
different worlds
This divide is meaningless, since what affect developers affect non developers ( as code that is not ported will no longer work, even for API change ), and as people keep speaking of scripts on yum. The command line switches are part of the API for software like puppet, ansible.
if someone takes the word "improve" in his mouth i don't see a place for "remove" in the same context
the "dirty codebase grown" that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it
that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users
In fact, since developers can fix bug more easily with a code that is clean, it benefits to users as well.
you ignore the bugs of missing functions which will be the first so you postponed the work only
That's why the developers do ask "what is missing". That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer.
a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces
Perfect, so are you leading the way, or do you continue to tell to people how to make a smart rewrite without being more specific and without putting any efforts?
my effort is try to prevent thousands of bugreports
Thousands ? I think you are exaggerating. Hyperbolic statements do not help.
did you realize that in this thread it was even suggested to completly remove the yum command over the long even if it is only a symlink?
Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface.
People who want the old yum can keep it alive, the others can use the dnf name.
throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution
You still didn't answer to the question I asked. How long do you want compatibility be kept, and what compatibility exactly ?
[snip of yum help]
That's neither the answer to : - how long - what
On 13.6.2014 14:58, Reindl Harald wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
why do so many developers not understand that simple fact?
I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do.
Look at tradition of BIND: - BIND 4 was the original version (AFAIK) - BIND 8 was complete re-write of v4 - BIND 9 was complete re-write of v8 - BIND 10 was another attempt to completely re-write it ...
Also, GNOME 3 and KDE 4 were mentioned several times.
IMHO keeping almost-compatible command "yum" forever is priceless.
Re-training all users to use different command is way more intrusive than simple fact that some "options" are missing in later version of software.
Users have to deal with it anyway because 100 % backwards compatibility is often just an illusion.
Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit :
On 13.6.2014 14:58, Reindl Harald wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
why do so many developers not understand that simple fact?
I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do.
Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ?
It happened in the past, and I do not remember seeing so much complains..
Am 14.06.2014 03:04, schrieb Michael Scherer:
Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit :
On 13.6.2014 14:58, Reindl Harald wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
why do so many developers not understand that simple fact?
I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do.
Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ?
It happened in the past, and I do not remember seeing so much complains..
maybe people just have enough of repeated iterations every few months breaking compatibility left and right while it would have been possible to replace/improve things without breakage
as said repeatly in that thread:
go ahead and propose to rename GNOME3 because it is no longer GNOME go ahead and propose to rename Linux because 3.15 is no longer Linux 1.0
and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it
Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:04, schrieb Michael Scherer:
Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit :
On 13.6.2014 14:58, Reindl Harald wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is.
the user expects that anyways if you replace something he did not asked for replace it and what just worked for him
why do so many developers not understand that simple fact?
I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do.
Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ?
It happened in the past, and I do not remember seeing so much complains..
maybe people just have enough of repeated iterations every few months breaking compatibility left and right while it would have been possible to replace/improve things without breakage
You may not realize, but having someone who do not do your job telling you how to do it is perceived as pretty annoying for a lot of people.
as said repeatly in that thread:
go ahead and propose to rename GNOME3 because it is no longer GNOME
Gnome is not a single software, it is a brand, and a collection of software. Keeping the brand is likely the reason why it was not renamed.
But the part that did change visually, ie the windows manager and the shell among others got renamed from whatever it was named to gnome-shell. Same goes for rhytmbox, afaik.
go ahead and propose to rename Linux because 3.15 is no longer Linux 1.0
I fail to see how comparing changes in more than 15 years is relevant to the current discussion. Nor even how anecdotal point of data is relevant.
and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it
it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ).
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way ?
Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean "keeping all the code and behavior until later" ?
Am 14.06.2014 03:24, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit :
Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ?
It happened in the past, and I do not remember seeing so much complains..
maybe people just have enough of repeated iterations every few months breaking compatibility left and right while it would have been possible to replace/improve things without breakage
You may not realize, but having someone who do not do your job telling you how to do it is perceived as pretty annoying for a lot of people.
you may not realize but having someone deciding changes and what you have to adopt on your setups is pretty annoying for a lot of people called "users"
as said repeatly in that thread:
go ahead and propose to rename GNOME3 because it is no longer GNOME
Gnome is not a single software, it is a brand, and a collection of software. Keeping the brand is likely the reason why it was not renamed.
But the part that did change visually, ie the windows manager and the shell among others got renamed from whatever it was named to gnome-shell. Same goes for rhytmbox, afaik.
that does not change the fact from the users point of view it is no longer GNOME
go ahead and propose to rename Linux because 3.15 is no longer Linux 1.0
I fail to see how comparing changes in more than 15 years is relevant to the current discussion. Nor even how anecdotal point of data is relevant.
i fail to see the need of rename the well known package manager
and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it
it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ).
because both where a complete different product and not just a new version, DNF is just a new version of YUM and that's what major version numbers are for
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way?
yes
Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean "keeping all the code and behavior until later" ?
jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:24, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit :
and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it
it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ).
because both where a complete different product and not just a new version, DNF is just a new version of YUM and that's what major version numbers are for
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way?
yes
so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ?
Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean "keeping all the code and behavior until later" ?
jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations
In the case of dnf, the plugin api did changed. And I doubt people want to bring back the old one. So the user expectation around specific plugin is already broken.
Yet, do you advocate bringing back the old API that no one liked, and more importantly, you volunteer to do that ?
Am 14.06.2014 03:42, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way?
yes
so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ?
it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all
Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean "keeping all the code and behavior until later" ?
jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations
In the case of dnf, the plugin api did changed. And I doubt people want to bring back the old one. So the user expectation around specific plugin is already broken.
no - only if you want it that way as developer
you could also say "OK, that's the currently used feature set and as we build the whole thing modular we can even ship that modules in the default install"
Yet, do you advocate bringing back the old API that no one liked, and more importantly, you volunteer to do that ?
no i advocate if someone starts to replace things he intergates the plugins instead demand others to do so - if i break API's i adopt code which is using it
Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:42, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way?
yes
so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ?
it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all
So why do you say "yes" at the proposal "that should be ok to break command line switch" if you mean "no" ?
So you are in favor of keeping the current behavior as is for how long ? ( because it sound like "forever" for you )
Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean "keeping all the code and behavior until later" ?
jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations
In the case of dnf, the plugin api did changed. And I doubt people want to bring back the old one. So the user expectation around specific plugin is already broken.
no - only if you want it that way as developer
Well, yes, because that's the developer that has to make the effort. It is easy to say "do that" and going back to your business. In the end, those who work decide. And so far, I do not see patches coming from you.
Am 14.06.2014 12:26, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:42, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way?
yes
so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ?
it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all
So why do you say "yes" at the proposal "that should be ok to break command line switch" if you mean "no" ?
to show you how weird your "come on let us break compatibility" is
So you are in favor of keeping the current behavior as is for how long ? (because it sound like "forever" for you)
yes forever to say it clear if it ain't broken don't fix it
Well, yes, because that's the developer that has to make the effort. It is easy to say "do that" and going back to your business. In the end, those who work decide. And so far, I do not see patches coming from you
i am fine with YUM for many years as others are too there was and is no valid reason to break CLI interfaces
That's why the developers do ask "what is missing". That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer
*full* compatibility - is that so hard to understand and why?
Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface.
why do you need to keep old code for compatible CLI interfaces?
People who want the old yum can keep it alive, the others can use the dnf name
and because of that attitude Linux don't have that big marketshare while often on that list is talked about competitors and marketshare
you will never gain a large userbase if you signal all the time that it's worthless for non-tech users to learn how to deal with whatever Linux systems because they have to learn again and again how to do the same things instead spend the time for learning how to do new things with their computers
Hi,
Been monitoring this debate and if nothing else this seems to point out that the reasoning for dnf, as opposed to fixing/rewriting yum haven't been laid out very well. I'm on yum side of the fence as I don't see that the reasoning so far is been put forward very well for moving to dnf, and that dnf has crept up on people rather than being 'out there'.
Played with dnf, and from as SA point of view (i.e. mine), I don't see the difference really, does what I need, which is good. But then so does yum, and there lies the problem. Bad/undocumented api's is not a good reason for starting something from starch, but a good reason to write this. At present, this feels like a pet project, rather than a project with good reasoning for existing. I'm sure that not the case, but its not good that I, and others, feel this well and points to really bad communication.
So my message is simple, write up why dnf is better than yum, from both a users and devs point of view, then maybe this'll win people over. Till I see that, I'll back the guys who want to stick with yum.
Cheers, Jon
On Sat, Jun 14, 2014 at 11:55 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.06.2014 12:26, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:42, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior,
command
lines switch, configuration and backend in a backward incompatible way?
yes
so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ?
it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all
So why do you say "yes" at the proposal "that should be ok to break command line switch" if you mean "no" ?
to show you how weird your "come on let us break compatibility" is
So you are in favor of keeping the current behavior as is for how long ? (because it sound like "forever" for you)
yes forever to say it clear if it ain't broken don't fix it
Well, yes, because that's the developer that has to make the effort. It is easy to say "do that" and going back to your business. In the end, those who work decide. And so far, I do not see patches coming from you
i am fine with YUM for many years as others are too there was and is no valid reason to break CLI interfaces
That's why the developers do ask "what is missing". That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer
*full* compatibility - is that so hard to understand and why?
Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface.
why do you need to keep old code for compatible CLI interfaces?
People who want the old yum can keep it alive, the others can use the dnf name
and because of that attitude Linux don't have that big marketshare while often on that list is talked about competitors and marketshare
you will never gain a large userbase if you signal all the time that it's worthless for non-tech users to learn how to deal with whatever Linux systems because they have to learn again and again how to do the same things instead spend the time for learning how to do new things with their computers
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 14. 6. 2014 at 12:18:07, Jon Kent wrote:
Hi,
Been monitoring this debate and if nothing else this seems to point out that the reasoning for dnf, as opposed to fixing/rewriting yum haven't been laid out very well. I'm on yum side of the fence as I don't see that the reasoning so far is been put forward very well for moving to dnf, and that dnf has crept up on people rather than being 'out there'.
Played with dnf, and from as SA point of view (i.e. mine), I don't see the difference really, does what I need, which is good. But then so does yum, and there lies the problem. Bad/undocumented api's is not a good reason for starting something from starch, but a good reason to write this. At present, this feels like a pet project, rather than a project with good reasoning for existing. I'm sure that not the case, but its not good that I, and others, feel this well and points to really bad communication.
So my message is simple, write up why dnf is better than yum, from both a users and devs point of view, then maybe this'll win people over. Till I see that, I'll back the guys who want to stick with yum.
Hi Jon, I will make this as short and simple as possible:
- dnf is maintainable in long term perspective, yum is not - dnf's well defined architecture allows: -- RFEs to come in more easily -- other programs to integrate better with it
The transition has nothing to do with user experience, it's all about the people making it. If someone steps up who is willing to maintain yum and keep up with the development in the area of rpm-based software management, be my guest.
To give you an example of what I'm talking about: recently we have introduced a concept of soft dependencies in rpm (yes, those that you know from Debian). Dnf will be able to handle them almost out of the box. Yum will maybe support them with some effort. Then we have the next big thing coming: rich dependencies (basically a simple boolean algebra in deps). There is no plan for yum to support those, the amount of effort required will just not be worth it.
Thanks Jan
Le samedi 14 juin 2014 à 12:55 +0200, Reindl Harald a écrit :
Am 14.06.2014 12:26, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 04:00 +0200, Reindl Harald a écrit :
Am 14.06.2014 03:42, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit :
So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way?
yes
so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ?
it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all
So why do you say "yes" at the proposal "that should be ok to break command line switch" if you mean "no" ?
to show you how weird your "come on let us break compatibility" is
So you are in favor of keeping the current behavior as is for how long ? (because it sound like "forever" for you)
yes forever to say it clear if it ain't broken don't fix it
Well, yes, because that's the developer that has to make the effort. It is easy to say "do that" and going back to your business. In the end, those who work decide. And so far, I do not see patches coming from you
i am fine with YUM for many years as others are too there was and is no valid reason to break CLI interfaces
That's why the developers do ask "what is missing". That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer
*full* compatibility - is that so hard to understand and why?
So basically, you want "full compatibility forever". Then I guess you cannot say that nobody ask for that, since you just did.
https://lists.fedoraproject.org/pipermail/devel/2014-June/199991.html
Yet, I still do not see you offering any help to achieve that, only you requiring it.
Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface.
why do you need to keep old code for compatible CLI interfaces?
Because that's the easiest way, especially for plugins.
Otherwise, any changes could result in unrelated side effects and regressions, and the more options you provides, the more stuff there is to break. And the QA cost of full compatibility is rather high, especially for python where there isn't much isolation or interface for the code ( ie, you can directly go to the internal structures, kinda like DOS years ago ).
Am 14.06.2014 15:04, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 12:55 +0200, Reindl Harald a écrit :
That's why the developers do ask "what is missing". That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer
*full* compatibility - is that so hard to understand and why?
So basically, you want "full compatibility forever". Then I guess you cannot say that nobody ask for that, since you just did.
https://lists.fedoraproject.org/pipermail/devel/2014-June/199991.html
stop that trolling
"to maintain yum in the long term" is a completly different thing than keep *full compatibility* - compatibility is independet from the YUM code itself
Yet, I still do not see you offering any help to achieve that, only you requiring it.
as you do not offering to do the work of re-view and adopt any existing script and howto out there
Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface.
why do you need to keep old code for compatible CLI interfaces?
Because that's the easiest way, especially for plugins.
interesting - guess what: the *easiest way* would have been not rewrite YUM at all - do it anyways but than say "but for all other things which don't match the cherry picking it's easier not do to so" is hypocrisy
Otherwise, any changes could result in unrelated side effects and regressions, and the more options you provides, the more stuff there is to break. And the QA cost of full compatibility is rather high, especially for python where there isn't much isolation or interface for the code ( ie, you can directly go to the internal structures, kinda like DOS years ago )
you understand that any compatibility break is a side effect for the user?
Le 14/06/2014 15:15, Reindl Harald a écrit :
stop that trolling
Weren't you the one trolling here ? Because that's what many people are thinking about this thread.
Don't you think that turning every discussion on DNF into a flame war is helpful or serves your purpose ? Even the ones where the maintainer requests feedback and help to improve the very same points you're complaining about ?
In a community, there are mainly two ways to influence its direction: a) do things yourself b) convincing the others that you're right
Like many here, you're not doing a) and you're doing poorly b), so either try to tone down your argumentation or learn how to use jedi mind tricks.
"to maintain yum in the long term" is a completly different thing than keep *full compatibility* - compatibility is independet from the YUM code itself
You were requesting that the Fedora Packages manager keeps the same user interface and behavior *forever* no matter how much broken it is. DNF has done a pretty good work, in keeping compatibility with yum. Besides, DNF is basically yum 4.0, nobody would complain if we were to break UI/behavior compatibility.
Yet, I still do not see you offering any help to achieve that, only you requiring it.
as you do not offering to do the work of re-view and adopt any existing script and howto out there
Fedora is not entitled to maintain third-party scripts but we might provide you some help if *you* ask.
you understand that any compatibility break is a side effect for the user?
You're not the only one who cares about user experience, please read the proposal. "This change will be completely transparent for users that use only the graphical package management tools. For anybody using the command line directly there will be some differences, but all the important operations are available with DNF, using the same CLI syntax."
I'm answering you out of kindness, but keep it the gentleman way or i'll request moderation, thanks.
Regards, H.
Am 14.06.2014 15:48, schrieb Haïkel Guémar:
Le 14/06/2014 15:15, Reindl Harald a écrit :
stop that trolling
Weren't you the one trolling here? Because that's what many people are thinking about this thread.
backed by what data?
Don't you think that turning every discussion on DNF into a flame war is helpful or serves your purpose ? Even the ones where the maintainer requests feedback and help to improve the very same points you're complaining about ?
don't you think if after i made clear my point of view a handful people starting quibbling is the real reason for become a flamewar?
In a community, there are mainly two ways to influence its direction: a) do things yourself b) convincing the others that you're right
Like many here, you're not doing a) and you're doing poorly b), so either try to tone down your argumentation or learn how to use jedi mind tricks.
tell that the two people who go repeatly off-topic
"to maintain yum in the long term" is a completly different thing than keep *full compatibility* - compatibility is independet from the YUM code itself
You were requesting that the Fedora Packages manager keeps the same user interface and behavior *forever* no matter how much broken it is
what eactly is broken in the CLI?
DNF has done a pretty good work, in keeping compatibility with yum. Besides, DNF is basically yum 4.0, nobody would complain if we were to break UI/behavior compatibility.
that must be why "dnf remove kernel" kills your system
Yet, I still do not see you offering any help to achieve that, only you requiring it.
as you do not offering to do the work of re-view and adopt any existing script and howto out there
Fedora is not entitled to maintain third-party scripts but we might provide you some help if *you* ask.
it would be enough not breaking them or stop pretend you create a operating system if Fedora drives in a direction to be a only self contained appliance with no care for other software running on tp of
you understand that any compatibility break is a side effect for the user?
You're not the only one who cares about user experience, please read the proposal. "This change will be completely transparent for users that use only the graphical package management tools. For anybody using the command line directly there will be some differences, but all the important operations are available with DNF, using the same CLI syntax."
oh yeah - proposals
is that the same one pretending a lower memory footprint while "dnf upgrade" on a VM with 192 MB RAM get killed by the kernel while "yum reinstall *" works fine?
250 MB RAM is a bad joke for a single process i have servers wich are doing the ir complete workload with less over months
I'm answering you out of kindness, but keep it the gentleman way or i'll request moderation, thanks
nice - threaten with moderation because you don't like someones opinion
Le 14/06/2014 15:59, Reindl Harald a écrit :
backed by what data?
Based on various contributors feedbacks.
don't you think if after i made clear my point of view a handful people starting quibbling is the real reason for become a flamewar?
Let's say that's the case, are you compelled to answer them ?
tell that the two people who go repeatly off-topic
They may have a different opinion about it, but if you agree to calm down the discussion, I'm pretty sure they will.
what eactly is broken in the CLI?
I'll chose an example you care about: protected packages. You pretend that DNF maintainers refused to support that, but actually, the answer is that they think it should be implemented as a plugin. I agree with you, most of the time, removing the running kernel is stupid but they are use cases where it makes sense. DNF maintainers felt that it should not be in core because it clutters the code and is restrictive for users.
A smarter move would be to (kindly) request that such plugin is written and enabled by default in F22.
that must be why "dnf remove kernel" kills your system
If I give you a riffle, and then you willingly shot yourself in the foot, don't complain.
it would be enough not breaking them or stop pretend you create a operating system if Fedora drives in a direction to be a only self contained appliance with no care for other software running on tp of
See, you're exaggerating, yum was around for 11 years, there are not many Linux Distribution that could claim having kept the same default package manager around. (Even Debian switched back between apt-get/aptitude). We've updated many core components at a faster pace and with more disruptive changes than yum/DNF.
oh yeah - proposals
is that the same one pretending a lower memory footprint while "dnf upgrade" on a VM with 192 MB RAM get killed by the kernel while "yum reinstall *" works fine?
250 MB RAM is a bad joke for a single process i have servers wich are doing the ir complete workload with less over months
What happens when you use "dnf reinstall *" ?
nice - threaten with moderation because you don't like someones opinion
If you're moderated, it won't be for your opinions (and *nobody* has the power to do that here) but for your behavior. Please notice, that I agreed that you raised some valid concerns. I prefer convincing you to be more considerate, and help you moving forward rather than requesting moderation (though, it won't be the first time and not by me). If you can't understand that your very behavior is preventing you to promote your agenda, well, I give up.
Regards, H.
Am 14.06.2014 16:39, schrieb Haïkel Guémar:
Le 14/06/2014 15:59, Reindl Harald a écrit :
what eactly is broken in the CLI?
I'll chose an example you care about: protected packages. You pretend that DNF maintainers refused to support that, but actually, the answer is that they think it should be implemented as a plugin. I agree with you, most of the time, removing the running kernel is stupid but they are use cases where it makes sense. DNF maintainers felt that it should not be in core because it clutters the code and is restrictive for users.
restrictive for users? the 1 out of a million can use "rpm -e"
A smarter move would be to (kindly) request that such plugin is written and enabled by default in F22.
a smarter way would have been write such plugin instead close the bugreport
that must be why "dnf remove kernel" kills your system
If I give you a riffle, and then you willingly shot yourself in the foot, don't complain
that is somehow different than replace the package-manager with a riffle
Am 14.06.2014 16:32, schrieb drago01:
"dnf remove yum dnf kernel" ruins your system yum don't allow that for good reasons
that's unacepptable behavior and was refused to change
I can list a tons of commands that "ruins your system" ... While I might understand why use "yum remove kernel" (to remove everything but the running kernel) the other commands do not make sense.
dd if=/dev/zero of=/dev/sda also "ruins the system" ... -> strawman
the strawman is on your side
* dd's job is to write raw data * the package managers job is help to maintain a machine and ruin it - especially if it did not many years before by doing exactly the same
dnf needs much more RAM currently while the feature page pretends it has a smaller footprint - so it's not ready or the feature page is a "would nice to be" not backed by the reality
Or maybe there is a bug (memory leak)? Did you file one?
i know the answer: nobody runs a system with 192 MB and it don't fullfill the Fedora minimum requirements so we don't care really because it works faster the way it works
On Sat, Jun 14, 2014 at 4:56 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.06.2014 16:39, schrieb Haïkel Guémar:
Le 14/06/2014 15:59, Reindl Harald a écrit :
[...]
- dd's job is to write raw data
- the package managers job is help to maintain a machine and ruin it
No its not ;)
- especially if it did not many years before
by doing exactly the same
dnf needs much more RAM currently while the feature page pretends it has a smaller footprint - so it's not ready or the feature page is a "would nice to be" not backed by the reality
Or maybe there is a bug (memory leak)? Did you file one?
i know the answer: nobody runs a system with 192 MB and it don't fullfill the Fedora minimum requirements so we don't care really because it works faster the way it works
Do you even care about problems that you find getting solved or are you just enjoining arguing on a mailing list?
Am 14.06.2014 17:26, schrieb drago01:
On Sat, Jun 14, 2014 at 4:56 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.06.2014 16:39, schrieb Haïkel Guémar:
Le 14/06/2014 15:59, Reindl Harald a écrit :
[...]
- dd's job is to write raw data
- the package managers job is help to maintain a machine and ruin it
No its not ;)
ok, you are just a troll
do me a and others a favor and hestitate repsond to anything i say because we both are incompatible since i point out real world problems and you are only provoke because it's fun for you knowing that i have a hard time to ignore such *censored myself*
- especially if it did not many years before by doing exactly the same
dnf needs much more RAM currently while the feature page pretends it has a smaller footprint - so it's not ready or the feature page is a "would nice to be" not backed by the reality
Or maybe there is a bug (memory leak)? Did you file one?
i know the answer: nobody runs a system with 192 MB and it don't fullfill the Fedora minimum requirements so we don't care really because it works faster the way it works
Do you even care about problems that you find getting solved or are you just enjoining arguing on a mailing list?
how do fedora-bugreports help if maintainers don't care anyways
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444574.html
On Sat, Jun 14, 2014 at 5:39 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.06.2014 17:26, schrieb drago01:
On Sat, Jun 14, 2014 at 4:56 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.06.2014 16:39, schrieb Haïkel Guémar:
Le 14/06/2014 15:59, Reindl Harald a écrit :
[...]
- dd's job is to write raw data
- the package managers job is help to maintain a machine and ruin it
No its not ;)
ok, you are just a troll
*you* are accusing others of trolling? seriously?
- especially if it did not many years before by doing exactly the same
dnf needs much more RAM currently while the feature page pretends it has a smaller footprint - so it's not ready or the feature page is a "would nice to be" not backed by the reality
Or maybe there is a bug (memory leak)? Did you file one?
i know the answer: nobody runs a system with 192 MB and it don't fullfill the Fedora minimum requirements so we don't care really because it works faster the way it works
Do you even care about problems that you find getting solved or are you just enjoining arguing on a mailing list?
how do fedora-bugreports help if maintainers don't care anyways
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444574.html
s/don't care/don't agree with you/ .. that happens.
Le samedi 14 juin 2014 à 15:15 +0200, Reindl Harald a écrit :
Am 14.06.2014 15:04, schrieb Michael Scherer:
Le samedi 14 juin 2014 à 12:55 +0200, Reindl Harald a écrit :
That's why the developers do ask "what is missing". That's also why I ask for you what compatibility you exactly want, and you keep avoiding giving a clear answer
*full* compatibility - is that so hard to understand and why?
So basically, you want "full compatibility forever". Then I guess you cannot say that nobody ask for that, since you just did.
https://lists.fedoraproject.org/pipermail/devel/2014-June/199991.html
stop that trolling
"to maintain yum in the long term" is a completly different thing than keep *full compatibility* - compatibility is independet from the YUM code itself
Given there is no specification of what you mean by "full compatibility", the compatibility is the current behaviour in every details, and the current behaviour is therefore linked to the current code.
Now, if someone do say "here is what we consider to be compatible" ( something that you have been asked 3 times and yet didn't provide, not even tried to provides ), then the compatibility would be separate from the code. But as long as "full compatibility" is "what yum does now", the 2 are linked by definition.
But again, can you give a more precise definition of the behaviour that should be kept without having to refer to yum code ? You do not even say what version of the yum code should be used as reference.
Yet, I still do not see you offering any help to achieve that, only you requiring it.
as you do not offering to do the work of re-view and adopt any existing script and howto out there
I did intend to work on ansible to have it using dnf API, as that's a codebase I know quite well.
Yes. And I would be in favor personally, so that let developers free to change the interface and anything if they see fit without having to keep old code for the old interface.
why do you need to keep old code for compatible CLI interfaces?
Because that's the easiest way, especially for plugins.
interesting - guess what: the *easiest way* would have been not rewrite YUM at all - do it anyways but than say "but for all other things which don't match the cherry picking it's easier not do to so" is hypocrisy
So basically, that exactly what I said. It is is easier to keep the old code than to ask to keep compatibility in the new one, especially since compatibility is not specified at all.
So if your goal is 100% compatibility over all, then indeed, not changing anything is the simplest way. Now, if you want to see some changes, then you are ok to have something change, so the goal is no longer 100%. So you have to explain what are the 90% that shouldn't changes at all, and what are the 10% that you are ok to see changes.
Otherwise, any changes could result in unrelated side effects and regressions, and the more options you provides, the more stuff there is to break. And the QA cost of full compatibility is rather high, especially for python where there isn't much isolation or interface for the code ( ie, you can directly go to the internal structures, kinda like DOS years ago )
you understand that any compatibility break is a side effect for the user?
Yes, I do. That doesn't mean that I care however.
I am personally ok with having some breakages if the developers think this is the better choice given time, contraints and all real life issues, as I trust them to have thought about it. And I do not care also because I am fully able to adapt, that's part of my job as sysadmin.
On Fri, 2014-06-13 at 14:53 +0200, Jan Zelený wrote:
So not wanting users to complain about “yum” no longer having some
features
is the only reason for dropping the yum name I have seen in this thread (also called “setting expectations”); have I missed other reasons?
No, there is not. But I think you misunderstood the reason, although not by much. The fact is that dnf *is* different project than yum, let's not try to mask it. The vast majority of code base is different (> 85% for sure), its architecture is different, the community is different, the entire nature of the project is different. And the fact that its CLI interface tries to be as compatible as possible with yum doesn't change any of this.
I understand that you want to rename the project to show that it is a new thing, but do users of yum really care about these facts? Do as a user you really care if bind 9 was a total rewrite of bind 8? I believe you overestimate how much users of software care about the inner workings.
That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum.
I again think you overestimate what users think of software. They don't think of yum as a particular code-base. Yum is the tool, like hammer is the tool. If you replace a hammer by a new redesigned hammer, it is still a hammer even if not 100% identical.
regards, Nikos
On Thu, Jun 12, 2014 at 10:09:13AM -0400, Chuck Anderson wrote:
And if those arguments aren't convincing enough, the second best option, if you MUST change the name of the command, is to change it ONCE to something PERMANENT that never changes ever again. Something generic like "package-manager" or "pkgman".
Heh, "apt-get".
Rich.
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user.
On 2014-06-11 14:07 (GMT-0400) DJ Delorie composed:
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user.
And in this particular case, the change is from a nice single finger word it's a two-hander, three finger.
On Wed, 2014-06-11 at 14:18 -0400, Felix Miata wrote:
On 2014-06-11 14:07 (GMT-0400) DJ Delorie composed:
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user.
And in this particular case, the change is from a nice single finger word it's a two-hander, three finger.
And as a user himself, above are the exact 2 reasons I hate this move. That it is better and/or becomes better due to backend and such, is no relevant (as long as its faster and easier anyway) really.
Still trying to figure out why initials for a name (if decide not gonna continue to use the *yum* name) was decided, instead of at least a different name/word that makes sense at least haha
On 11 June 2014 23:31, Mike Chambers mike@mtchambers.com wrote:
Still trying to figure out why initials for a name (if decide not gonna continue to use the *yum* name) was decided, instead of at least a different name/word that makes sense at least haha
In addition to the user confusion for the command as things stand right now in F20 dnf and yum do not share a history database.
The yum history command is a very useful tool - will these databases merge or would the old history basically get lost?
Dne 11.6.2014 20:18, Felix Miata napsal(a):
On 2014-06-11 14:07 (GMT-0400) DJ Delorie composed:
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user.
And in this particular case, the change is from a nice single finger word it's a two-hander, three finger.
Eh ... Writing DNF by both hands and 3 fingers should be faster then typing YUM by single finger. But if you are using just pointer fingers of your both hands, then I can understand your point ;)
BTW people who are using Czech or German keyboard layout would disagree with your argument anyway (hint: Y <-> Z).
Vít
On 11. 6. 2014 at 14:07:05, DJ Delorie wrote:
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user.
I'm sorry but at this point I feel I gotta ask: have you read my earlier replies?
Nothing will change for you, the yum command will still exist for a few more Fedora releases, just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists.
Thanks Jan
On Thu, Jun 12, 2014 at 10:01:22AM +0200, Jan Zelený wrote:
On 11. 6. 2014 at 14:07:05, DJ Delorie wrote:
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user.
I'm sorry but at this point I feel I gotta ask: have you read my earlier replies?
Nothing will change for you, the yum command will still exist for a few more Fedora releases, just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists.
At least "systemctl" is generic unlike "dnf". And systemctl is much more of a change from the way "service" works that it warranted a change of name. "yum" and "dnf" both work pretty much the same way from the user's perspective, so it is not a good argument to change the name.
On 12. 6. 2014 at 10:11:40, Chuck Anderson wrote:
On Thu, Jun 12, 2014 at 10:01:22AM +0200, Jan Zelený wrote:
On 11. 6. 2014 at 14:07:05, DJ Delorie wrote:
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user.
I'm sorry but at this point I feel I gotta ask: have you read my earlier replies?
Nothing will change for you, the yum command will still exist for a few more Fedora releases, just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists.
At least "systemctl" is generic unlike "dnf". And systemctl is much more of a change from the way "service" works that it warranted a change of name. "yum" and "dnf" both work pretty much the same way from the user's perspective, so it is not a good argument to change the name.
Actually it is. The "pretty much" part is exactly the reason why to change the name. If we didn't, a ton of users who are not reading this conversation would start filing regression bugs. If we set their expectations right, warning them that yum is no more, they are far less likely to do so.
Thanks Jan
Am 12.06.2014 16:28, schrieb Jan Zelený:
On 12. 6. 2014 at 10:11:40, Chuck Anderson wrote:
At least "systemctl" is generic unlike "dnf". And systemctl is much more of a change from the way "service" works that it warranted a change of name. "yum" and "dnf" both work pretty much the same way from the user's perspective, so it is not a good argument to change the name.
Actually it is. The "pretty much" part is exactly the reason why to change the name. If we didn't, a ton of users who are not reading this conversation would start filing regression bugs. If we set their expectations right, warning them that yum is no more, they are far less likely to do so.
wrong
* you get that regression bugs anyways * the only thing what you are doing is spread confusion
in case of "set their expectations right"
* why was GNOME3 not renamed * why was KDE4 not renamed * why was Apache 2.4 not renamed
the only expectation a user has is that behavior don't change and features / options are not removed and called "improvement"
Actually it is. The "pretty much" part is exactly the reason why to change the name. If we didn't, a ton of users who are not reading this conversation would start filing regression bugs. If we set their expectations right, warning them that yum is no more, they are far less likely to do so.
The right way to handle this is the way that every other package handles it. Detect the no-longer-compatible option and tell the user "that option is no longer available". That way, the only users who are ever inconvenienced are the few that are using the obsolete option.
The wrong way to solve this is to inconvenience *every* user for the sake of the few who need it.
Nothing will change for you, the yum command will still exist for a few more Fedora releases,
Which only postpones the problem.
just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists.
Which is currently annoying me, for the same reason.
On 12. 6. 2014 at 10:54:45, DJ Delorie wrote:
Nothing will change for you, the yum command will still exist for a few more Fedora releases,
Which only postpones the problem.
just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists.
Which is currently annoying me, for the same reason.
I'm sorry you feel this way. Most of the people I talked to are quite happy how this transition was handled. That's why I consider it a good strategy for dnf as well. If you have any other suggestions other than keeping the name, we will be open to consider them.
Thanks Jan
On Fri, Jun 13, 2014 at 09:38:40AM +0200, Jan Zelený wrote:
On 12. 6. 2014 at 10:54:45, DJ Delorie wrote:
Nothing will change for you, the yum command will still exist for a few more Fedora releases,
Which only postpones the problem.
just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists.
Which is currently annoying me, for the same reason.
I'm sorry you feel this way. Most of the people I talked to are quite happy how this transition was handled. That's why I consider it a good strategy for dnf as well. If you have any other suggestions other than keeping the name, we will be open to consider them.
The command name doesn't have to match the project name. E.g. just look at the ImageMagick package--there are tons of generic command names that don't mention "ImageMagick" (or any abbreviation thereof) in their names:
rpm -ql ImageMagick|grep bin
/usr/bin/animate /usr/bin/compare /usr/bin/composite /usr/bin/conjure /usr/bin/convert /usr/bin/display /usr/bin/identify /usr/bin/import /usr/bin/mogrify /usr/bin/montage /usr/bin/stream
So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for "the tool that installs, removes, and updates packages". I propose that this command name be called "pkg". We can keep backwards compatibility to both the "yum" command name and the "dnf" command name indefinitely.
On 13. 6. 2014 at 10:09:07, Chuck Anderson wrote:
On Fri, Jun 13, 2014 at 09:38:40AM +0200, Jan Zelený wrote:
On 12. 6. 2014 at 10:54:45, DJ Delorie wrote:
Nothing will change for you, the yum command will still exist for a few more Fedora releases,
Which only postpones the problem.
just as the `service` command that was superseded by systemctl
like
5 releases of Fedora ago exists.
Which is currently annoying me, for the same reason.
I'm sorry you feel this way. Most of the people I talked to are quite happy how this transition was handled. That's why I consider it a good strategy for dnf as well. If you have any other suggestions other than keeping the name, we will be open to consider them.
The command name doesn't have to match the project name. E.g. just look at the ImageMagick package--there are tons of generic command names that don't mention "ImageMagick" (or any abbreviation thereof)
in their names:
rpm -ql ImageMagick|grep bin
/usr/bin/animate /usr/bin/compare /usr/bin/composite /usr/bin/conjure /usr/bin/convert /usr/bin/display /usr/bin/identify /usr/bin/import /usr/bin/mogrify /usr/bin/montage /usr/bin/stream
So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for "the tool that installs, removes, and updates packages". I propose that this command name be called "pkg". We can keep backwards compatibility to both the "yum" command name and the "dnf" command name indefinitely.
Sounds like an interesting idea and we will definitely give this some thought. It needs some more work thought to see if it makes sense. For example what would you say should be the correlation between the pkg command and DNF's Python API? What I mean is which of these two would you say is better if we go for this "neutral" command?
import dnf
- or -
import pkg
Thanks Jan
On Mon, Jun 16, 2014 at 09:31:17AM +0200, Jan Zelený wrote:
On 13. 6. 2014 at 10:09:07, Chuck Anderson wrote:
On Fri, Jun 13, 2014 at 09:38:40AM +0200, Jan Zelený wrote:
On 12. 6. 2014 at 10:54:45, DJ Delorie wrote:
Nothing will change for you, the yum command will still exist for a few more Fedora releases,
Which only postpones the problem.
just as the `service` command that was superseded by systemctl
like
5 releases of Fedora ago exists.
Which is currently annoying me, for the same reason.
I'm sorry you feel this way. Most of the people I talked to are quite happy how this transition was handled. That's why I consider it a good strategy for dnf as well. If you have any other suggestions other than keeping the name, we will be open to consider them.
The command name doesn't have to match the project name. E.g. just look at the ImageMagick package--there are tons of generic command names that don't mention "ImageMagick" (or any abbreviation thereof)
in their names:
rpm -ql ImageMagick|grep bin
/usr/bin/animate /usr/bin/compare /usr/bin/composite /usr/bin/conjure /usr/bin/convert /usr/bin/display /usr/bin/identify /usr/bin/import /usr/bin/mogrify /usr/bin/montage /usr/bin/stream
So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for "the tool that installs, removes, and updates packages". I propose that this command name be called "pkg". We can keep backwards compatibility to both the "yum" command name and the "dnf" command name indefinitely.
Sounds like an interesting idea and we will definitely give this some thought. It needs some more work thought to see if it makes sense. For example what would you say should be the correlation between the pkg command and DNF's Python API? What I mean is which of these two would you say is better if we go for this "neutral" command?
import dnf
- or -
import pkg
I don't think the programmer's API needs to be changed. It can stay dnf if you want. All I care about in this discussion is the User Interface.
On 16 June 2014 08:31, Jan Zelený jzeleny@redhat.com wrote:
On 13. 6. 2014 at 10:09:07, Chuck Anderson wrote:
So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for "the tool that installs, removes, and updates packages". I propose that this command name be called "pkg". We can keep backwards compatibility to both the "yum" command name and the "dnf" command name indefinitely.
Sounds like an interesting idea and we will definitely give this some thought.
If you decide to go this route, it's worth bearing in mind that Solaris 11 and FreeBSD 10 both already have tools called "pkg" that perform this function. They are incompatible with yum and dnf, but have a similar-enough command-line that people searching the web for, say, "pkg install" will find information about the wrong one.
On 16. 6. 2014 at 19:49:35, Peter Oliver wrote:
On 16 June 2014 08:31, Jan Zelený jzeleny@redhat.com wrote:
On 13. 6. 2014 at 10:09:07, Chuck Anderson wrote:
So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for "the tool that installs, removes, and updates packages". I propose that this command name be called "pkg". We can keep backwards compatibility to both the "yum" command name and the "dnf" command name indefinitely.
Sounds like an interesting idea and we will definitely give this some thought.
If you decide to go this route, it's worth bearing in mind that Solaris 11 and FreeBSD 10 both already have tools called "pkg" that perform this function. They are incompatible with yum and dnf, but have a similar-enough command-line that people searching the web for, say, "pkg install" will find information about the wrong one.
Any other suggestions then? Cause `pkg` would be my #1 choice.
Thanks Jan
fpm (fedora package manager). Flows nicely off the keyboard too 😊
I'd agree that dnf is perhaps not the best name in the world, always makes me think 'did not finish' which isn't good really.
Jon On 17 Jun 2014 08:07, "Jan Zelený" jzeleny@redhat.com wrote:
On 16. 6. 2014 at 19:49:35, Peter Oliver wrote:
On 16 June 2014 08:31, Jan Zelený jzeleny@redhat.com wrote:
On 13. 6. 2014 at 10:09:07, Chuck Anderson wrote:
So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for "the tool that installs, removes, and updates packages". I propose that this command name be called "pkg". We can keep backwards compatibility to both the "yum" command name and the "dnf" command name indefinitely.
Sounds like an interesting idea and we will definitely give this some thought.
If you decide to go this route, it's worth bearing in mind that Solaris 11 and FreeBSD 10 both already have tools called "pkg" that perform this function. They are incompatible with yum and dnf, but have a similar-enough command-line that people searching the web for, say, "pkg install" will find information about the wrong one.
Any other suggestions then? Cause `pkg` would be my #1 choice.
Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 17.06.2014 09:13, Jon Kent wrote:
fpm (fedora package manager). Flows nicely off the keyboard too 😊
fedora package manager aka fpm in EL8? :) So for a couple of years here we go again. BTW yum & "never finished one" are based on the actual package manager - rpm. man 8 yum "yum is an interactive, rpm based, package manager.".
So interactive package manager aka irpm(TM) should suffice. :)
poma
On Tue, Jun 17, 2014 at 3:46 AM, poma pomidorabelisima@gmail.com wrote:
fedora package manager aka fpm in EL8? :) So for a couple of years here we go again. BTW yum & "never finished one" are based on the actual package manager - rpm. man 8 yum "yum is an interactive, rpm based, package manager.".
So interactive package manager aka irpm(TM) should suffice. :)
But it's new. We should be able to do something with the word "new". How about:
New Original Object-oriented packaGe Installer and Eraser?
New Advantageous Package And Lox Manager?
New Effervescent Volumizer Extraordinaire, Ridiculously Masculine Installer, and Neato Deinstaller?
Am 17.06.2014 17:54, schrieb Jerry James:
On Tue, Jun 17, 2014 at 3:46 AM, poma pomidorabelisima@gmail.com wrote:
fedora package manager aka fpm in EL8? :) So for a couple of years here we go again. BTW yum & "never finished one" are based on the actual package manager - rpm. man 8 yum "yum is an interactive, rpm based, package manager.".
So interactive package manager aka irpm(TM) should suffice. :)
But it's new. We should be able to do something with the word "new"
and in the next iteration? new makes no sense at all and should be *hardly* avoided in general
* 2014: new .... * 2018: newer .... * 2022: really new .....
----- Original Message -----
From: "Jan Zelený" jzeleny@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, June 17, 2014 9:07:39 AM Subject: Re: F22 System Wide Change: Replace Yum With DNF
On 16. 6. 2014 at 19:49:35, Peter Oliver wrote:
On 16 June 2014 08:31, Jan Zelený jzeleny@redhat.com wrote:
On 13. 6. 2014 at 10:09:07, Chuck Anderson wrote:
So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for "the tool that installs, removes, and updates packages". I propose that this command name be called "pkg". We can keep backwards compatibility to both the "yum" command name and the "dnf" command name indefinitely.
Sounds like an interesting idea and we will definitely give this some thought.
If you decide to go this route, it's worth bearing in mind that Solaris 11 and FreeBSD 10 both already have tools called "pkg" that perform this function. They are incompatible with yum and dnf, but have a similar-enough command-line that people searching the web for, say, "pkg install" will find information about the wrong one.
Any other suggestions then? Cause `pkg` would be my #1 choice.
Thanks
rpm-(re)solve? pkg-(re)solve? pkgmanage? pkgmgmt?... :-/
Hm, 'pkg' is the best.
On Tue, Jun 17, 2014 at 3:07 AM, Jan Zelený jzeleny@redhat.com wrote:
Any other suggestions then? Cause `pkg` would be my #1 choice.
rum: {Redhat,RPM} Updater, Modified rup: {Redhat,RPM} UPdater packagectl
Rich
On Tue, 17 Jun 2014 09:07:39 +0200 Jan Zelený jzeleny@redhat.com wrote:
Any other suggestions then? Cause `pkg` would be my #1 choice.
Personally, I think adding another name just adds another problem.
kevin
On Tue, 17 Jun 2014 08:03:20 -0600 Kevin Fenzi kevin@scrye.com wrote:
On Tue, 17 Jun 2014 09:07:39 +0200 Jan Zelený jzeleny@redhat.com wrote:
Any other suggestions then? Cause `pkg` would be my #1 choice.
Personally, I think adding another name just adds another problem.
kevin
This, please do not invent some generic name and be forced in 10 years to rename yet again with the same arguments.
Either keep the dnf name:
- and update all documentation basically with s/yum/dnf/g - and make sure it's big in the release notes - and provide a yum frontend with compatibility warnings
or rename dnf to yum and call it 4.0:
- and warn programmers that the interface has changed - and make sure that obsoleted options warn of changed defaults
My preference is the latter, basically because I don't see the wins in the first case, FWIW.
--Stijn
Am 17.06.2014 21:36, schrieb Stijn Hoop:
On Tue, 17 Jun 2014 08:03:20 -0600 Kevin Fenzi kevin@scrye.com wrote:
On Tue, 17 Jun 2014 09:07:39 +0200 Jan Zelený jzeleny@redhat.com wrote:
Any other suggestions then? Cause `pkg` would be my #1 choice.
Personally, I think adding another name just adds another problem.
kevin
This, please do not invent some generic name and be forced in 10 years to rename yet again with the same arguments.
Either keep the dnf name:
- and update all documentation basically with s/yum/dnf/g
- and make sure it's big in the release notes
- and provide a yum frontend with compatibility warnings
the problem is you can't update all documentations out there
that is an ongoing problem - there are here and there howtos for setups built with more than one component and if it comes to changes here and there without a very good reason the step-by-step howto becomes invalid
or rename dnf to yum and call it 4.0:
- and warn programmers that the interface has changed
- and make sure that obsoleted options warn of changed defaults
My preference is the latter, basically because I don't see the wins in the first case, FWIW
+1
a new major version always indicates that there may be some *well justified changes* and thats why major.minor.bugfix exists - sadly these days more and more projetcs ignore this vesioning by missing knowledge or not care and follow google chrome
Please keep the command name "yum", and keep the command line syntax and the configuration language as compatible as is feasible. Make a wrapper or a symlink if you need to, but plan to keep it forever, not just for a year or two.
So Yum has been made faster? That's wonderful news, it was certainly needed. It's been redesigned and largely rewritten? OK, great, I understand that the new design is better. If there was some feature that turned out to be a misfeature and had to be removed, well that's unfortunate but it happens. Remove the misfeature, document that it's gone and that it was a bad idea from the beginning, and print an informative error message when someone tries to use it. If a feature that was optional before is now always enabled, then keep the option as a no-op and document that it has no effect anymore. As a user of Yum I don't see any of that as a reason to change the command name.
As a system administrator I expect "yum install", "yum remove" and "yum update" to continue to work, and I expect to not have to rename or edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone.
As a fellow programmer I can understand that you want to use a new name for this new and improved program that you have invested a lot of work in, but I also know how annoyed I would be if I had scripts calling Yum, and had to modify them to keep them working. A command line interface is also an API, and I want APIs to be as stable as possible so I can spend my time writing new programs instead of rewriting old programs just to keep existing functionality. It's particularly painful when a program must be ported or branched to work on different systems, for example Fedora and RHEL, because one has only the old API and the other has only the new API.
On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
Please keep the command name "yum", and keep the command line syntax and the configuration language as compatible as is feasible. Make a wrapper or a symlink if you need to, but plan to keep it forever, not just for a year or two.
So Yum has been made faster? That's wonderful news, it was certainly needed. It's been redesigned and largely rewritten? OK, great, I understand that the new design is better. If there was some feature that turned out to be a misfeature and had to be removed, well that's unfortunate but it happens. Remove the misfeature, document that it's gone and that it was a bad idea from the beginning, and print an informative error message when someone tries to use it. If a feature that was optional before is now always enabled, then keep the option as a no-op and document that it has no effect anymore. As a user of Yum I don't see any of that as a reason to change the command name.
As a system administrator I expect "yum install", "yum remove" and "yum update" to continue to work, and I expect to not have to rename or edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone.
As a fellow programmer I can understand that you want to use a new name for this new and improved program that you have invested a lot of work in, but I also know how annoyed I would be if I had scripts calling Yum, and had to modify them to keep them working. A command line interface is also an API, and I want APIs to be as stable as possible so I can spend my time writing new programs instead of rewriting old programs just to keep existing functionality. It's particularly painful when a program must be ported or branched to work on different systems, for example Fedora and RHEL, because one has only the old API and the other has only the new API.
-- Björn Persson
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Amen. I've been wanting to chime in here, but this is exactly how I feel on the issue and you've said it better than I could have.
Ben Rosser
On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
Please keep the command name "yum", and keep the command line syntax and the configuration language as compatible as is feasible. Make a wrapper or a symlink if you need to, but plan to keep it forever, not just for a year or two.
The name change is gong to break every 'chef' cookbook that uses the 'yum_package' utility, until chef can be profoundly upgraded to support dnf. Similar issues will occur with cfengine and many, many other system management utilities.
I think the name change helps make clear that it's an architectural change.
So Yum has been made faster? That's wonderful news, it was certainly needed. It's been redesigned and largely rewritten? OK, great, I
I'm afraid that It's also a fairly irrelevant speed improvement. Many of the underlying delays in yum are due to the excessively bulky repodata, which requires complete binary replacement every time yum metadata expires due to its overburdened and monolithic compressed binary format. Unless 'repodata' is extensively rewritten, with much smaller and easily synchronzed components and not this monolithinc and increasingly encumbered SQLite database of doom, small operations such as "yum check-updates" are likely to continue to suck bandwidth, CPU, and resources excessively every time they get run.
If you think I'm kidding, switch to a local yum mirror and check the logs for *just how many times*, the repodata gets downloaded with standard configurations in a busy environment. The bandwidth saved by using delta-rpms is completely irrelevant compared to the expensive repodata refreshes, themselves, in an environment where yum checks, or system tools that verify yum dependencies, run even once a day. Frankly, improving that might be enormously helpful to the Fedora mirrors themselves. The investment in server side operations to check a larger list of smaller and more stable metadata components would, I think, be well justified by replacing the quite builky, monolithic, and expiration envorced sqlite database files.
I'd love to see dnf speed improvements improve the behavior of tools like 'mock', which rely so heavily on yum updates. But given the bandwidth and resource constraints of repodata churn, I don't think it's gonna happen.
As a system administrator I expect "yum install", "yum remove" and "yum update" to continue to work, and I expect to not have to rename or edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone.
That's why they're changing the name: it's a major architectural shift in a core component, and continuing to call it yum, could be confusing.
As a fellow programmer I can understand that you want to use a new name for this new and improved program that you have invested a lot of work in, but I also know how annoyed I would be if I had scripts calling Yum, and had to modify them to keep them working. A command line interface is also an API, and I want APIs to be as stable as possible so I can spend my time writing new programs instead of rewriting old programs just to keep existing functionality. It's particularly painful when a program must be ported or branched to work on different systems, for example Fedora and RHEL, because one has only the old API and the other has only the new API.
And the API changing is pretty profound. It's a different API, thus a different function name.
And yeah, I'm not personally looking forward to it. I still loathe the switch to systemd for systems I maintain in multiple environments.
-- Björn Persson
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Nico Kadel-Garcia wrote:
On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
As a system administrator I expect "yum install", "yum remove" and "yum update" to continue to work, and I expect to not have to rename or edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone.
That's why they're changing the name: it's a major architectural shift in a core component, and continuing to call it yum, could be confusing.
That argument contradicts this quote from the feature page:
| letting system administrators (including users who routinely manage | their packages using the legacy Yum) perform all common packaging | operations using DNF, with no or minimal and documented change to | the command syntax, apart from replacing the command name.
The user interface can't both be so similar that the difference can be described as "no or minimal change", and at the same time so radically different that every user must be made painfully aware of the change.
On Sun, Jun 15, 2014 at 2:18 PM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
Nico Kadel-Garcia wrote:
On Sat, Jun 14, 2014 at 3:56 PM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
As a system administrator I expect "yum install", "yum remove" and "yum update" to continue to work, and I expect to not have to rename or edit /etc/yum.conf after an upgrade. I'm sure I'm far from alone.
That's why they're changing the name: it's a major architectural shift in a core component, and continuing to call it yum, could be confusing.
That argument contradicts this quote from the feature page:
| letting system administrators (including users who routinely manage | their packages using the legacy Yum) perform all common packaging | operations using DNF, with no or minimal and documented change to | the command syntax, apart from replacing the command name.
The user interface can't both be so similar that the difference can be described as "no or minimal change", and at the same time so radically different that every user must be made painfully aware of the change.
Look for the weasel words. "minimal and documented change to the command syntax," The *documented* changes, such as the handling of dependencies and of "protected" components, are profound and dangerous enough to justify a distinct. If the changes were less profound. It's still a repodata back end, it's still RPM under the hood: It's basically a refitted dashboard on the same old car.
-
Andrew Clayton -
Ben Rosser -
Björn Persson -
Chris Adams -
Chuck Anderson -
David -
Dennis Gilmore -
DJ Delorie -
drago01 -
Felix Miata -
Haïkel -
Howard Howell -
Ian Malone -
James Hogarth -
Jamie Duncan -
Jan Zelený -
Jaroslav Reznik -
Jerry James -
Jon Kent -
Kevin Fenzi -
Luya Tshimbalanga -
Mathieu Bridon -
Matthew Miller -
Michael Scherer -
Mike Chambers -
Mikolaj Izdebski -
Miloslav Trmač -
Miroslav Suchý -
Nico Kadel-Garcia -
Nikos Mavrogiannopoulos -
Olav Vitters -
Peter Jones -
Peter Oliver -
Petr Spacek -
Pierre-Yves Chibon -
poma -
Przemek Klosowski -
Pádraig Brady -
Radek Holy -
Rahul Sundaram -
Reindl Harald -
Rich Mattes -
Richard Hughes -
Richard W.M. Jones -
Simo Sorce -
Steve Clark -
Stijn Hoop -
Tomas Mraz -
Vít Ondruch