look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
and yes "yum remove kernel" is a *minimum* to handeled properly
there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines guess how abused they are if they have completly different behavior because dveleopers tend to call anything they don't like to implement a "border case"
On 2 January 2014 15:28, Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
DNF isn't due to replace yum until F22.
please realize that a drop-in replacement *first* needs to be *really* drop-in
It's not a drop-in replacement. This is my last email to this thread.
Richard.
Am 02.01.2014 16:51, schrieb Richard Hughes:
On 2 January 2014 15:28, Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
DNF isn't due to replace yum until F22.
which may arrive in 2014 givern that F20 was released 2013/12 that's why i start to complain *before* it is too late
please realize that a drop-in replacement *first* needs to be *really* drop-in
It's not a drop-in replacement.
and *that* is a problem. if something is going to replace a well working and existing piece of software it should support it's capabilities completly and before not be considered as release quality
This is my last email to this thread
calm down
signed completely.
using fed since core, it makes me stupid, to rethink after every update. one system is deleted, cause it never was stable after an upgrade.
regards,
joern rink Am 02.01.2014 17:01 schrieb "Reindl Harald" h.reindl@thelounge.net:
Am 02.01.2014 16:51, schrieb Richard Hughes:
On 2 January 2014 15:28, Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
DNF isn't due to replace yum until F22.
which may arrive in 2014 givern that F20 was released 2013/12 that's why i start to complain *before* it is too late
please realize that a drop-in replacement *first* needs to be *really* drop-in
It's not a drop-in replacement.
and *that* is a problem. if something is going to replace a well working and existing piece of software it should support it's capabilities completly and before not be considered as release quality
This is my last email to this thread
calm down
-- 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 Thu, Jan 02, 2014 at 04:28:59PM +0100, Reindl Harald wrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
Why did you even bother posting this message, if not to dismiss the hard work of people who actually do stuff, rather than spending all day trolling?
DNF is a planned replacement (some time in the future). Ales is quite correctly asking for feedback and opening things up to a wider userbase. Some things don't work, as he is aware.
Rich.
Am 02.01.2014 17:35, schrieb Richard W.M. Jones:
On Thu, Jan 02, 2014 at 04:28:59PM +0100, Reindl Harald wrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
Why did you even bother posting this message, if not to dismiss the hard work of people who actually do stuff, rather than spending all day trolling?
to prevent that the same as with GRUB2 and systemd way too early made it in a stable release happening again - and after that get again "why are you open your mouth now and not due testing" back
if this is "trolling" in your eyes i can't help you
replacing things too soon means lacking of functionality and bugs in cases which worked perfect over years - so for me if someone is going out and replace working things there must be a very good reason to do so and the minimum acceptance is that it must provide *all* capabilities of what is replaced
DNF is a planned replacement (some time in the future). Ales is quite correctly asking for feedback and opening things up to a wider userbase. Some things don't work, as he is aware
oh yeah "i see" with answers like "In practice however, a user doesn't type 'dnf erase -y kernel' by accident" - no i distribute "yum -y remove kernel" since years over a infrastructure *because i know* yum would never remove the running kernel
"If there are specific plugins you'd like to see sooner please open bugs for them" - oh no - the other way round things are working, there are yum-plugins over years in the fedora repos, so if someone goes out and start replacing yum he do not need bugreports
On Thu, Jan 02, 2014 at 05:54:00PM +0100, Reindl Harald wrote:
to prevent that the same as with GRUB2 and systemd way too early made it in a stable release happening again - and after that get again "why are you open your mouth now and not due testing" back
I'm sure that Ales will welcome patches from you.
But, have you ever contributed a patch to Fedora? I'm having difficulty finding any. The first match for a Google search "reindl harald fedora" is a discussion about banning you from sending mail to this mailing list. You don't even have a Fedora account.
Rich.
why are *that* agressive?
Am 02.01.2014 18:16, schrieb Richard W.M. Jones:
On Thu, Jan 02, 2014 at 05:54:00PM +0100, Reindl Harald wrote:
to prevent that the same as with GRUB2 and systemd way too early made it in a stable release happening again - and after that get again "why are you open your mouth now and not due testing" back
I'm sure that Ales will welcome patches from you But, have you ever contributed a patch to Fedora?
contribution for you is only writing the code? that below is not contribution in your eyes?
testing hundrets of packages including kernel straight after build and give feedback is not contributing in your eyes?
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108 https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3 https://bugzilla.redhat.com/show_bug.cgi?id=1019244 https://bugzilla.redhat.com/show_bug.cgi?id=1019245 https://bugzilla.redhat.com/show_bug.cgi?id=1019247 https://bugzilla.redhat.com/show_bug.cgi?id=1019249 https://bugzilla.redhat.com/show_bug.cgi?id=1019251 https://bugzilla.redhat.com/show_bug.cgi?id=1019312 https://bugzilla.redhat.com/show_bug.cgi?id=1019333 https://bugzilla.redhat.com/show_bug.cgi?id=1019337 https://bugzilla.redhat.com/show_bug.cgi?id=1019253 https://bugzilla.redhat.com/show_bug.cgi?id=1019254 https://bugzilla.redhat.com/show_bug.cgi?id=1019256 https://bugzilla.redhat.com/show_bug.cgi?id=1019259 https://bugzilla.redhat.com/show_bug.cgi?id=983604 https://bugzilla.redhat.com/show_bug.cgi?id=984181 https://bugzilla.redhat.com/show_bug.cgi?id=1008385 https://bugzilla.redhat.com/show_bug.cgi?id=983615 https://bugzilla.redhat.com/show_bug.cgi?id=1008400 https://bugzilla.redhat.com/show_bug.cgi?id=996735 https://bugzilla.redhat.com/show_bug.cgi?id=983606 https://bugzilla.redhat.com/show_bug.cgi?id=983623 https://bugzilla.redhat.com/show_bug.cgi?id=984185 https://bugzilla.redhat.com/show_bug.cgi?id=990052 https://bugzilla.redhat.com/show_bug.cgi?id=990055 https://bugzilla.redhat.com/show_bug.cgi?id=1000643 https://bugzilla.redhat.com/show_bug.cgi?id=973458
I'm having difficulty finding any. The first match for a Google search "reindl harald fedora" is a discussion about banning you from sending mail to this mailing list
and if you look the referred mail was *never* sent to any list as well the whole topic was not at devel until a private message was sent from the original RCPT to devel as CC
You don't even have a Fedora account
how did i give karma for around 900 updates in 2013
On 01/02/2014 06:16 PM, Richard W.M. Jones wrote:
On Thu, Jan 02, 2014 at 05:54:00PM +0100, Reindl Harald wrote:
to prevent that the same as with GRUB2 and systemd way too early made it in a stable release happening again - and after that get again "why are you open your mouth now and not due testing" back
I'm sure that Ales will welcome patches from you.
But, have you ever contributed a patch to Fedora? I'm having difficulty finding any. The first match for a Google search "reindl harald fedora" is a discussion about banning you from sending mail to this mailing list. You don't even have a Fedora account.
I see no reason for ad hominem attacks. Personal history is irrelevant here. Let's please keep civil and focus on facts.
Aleš announced DNF ready for user testing, this thread is a legitimate reply to that (though this list may be the wrong channel for it).
Am 02.01.2014 18:30, schrieb Petr Viktorin:
On 01/02/2014 06:16 PM, Richard W.M. Jones wrote:
On Thu, Jan 02, 2014 at 05:54:00PM +0100, Reindl Harald wrote:
to prevent that the same as with GRUB2 and systemd way too early made it in a stable release happening again - and after that get again "why are you open your mouth now and not due testing" back
I'm sure that Ales will welcome patches from you.
But, have you ever contributed a patch to Fedora? I'm having difficulty finding any. The first match for a Google search "reindl harald fedora" is a discussion about banning you from sending mail to this mailing list. You don't even have a Fedora account.
I see no reason for ad hominem attacks. Personal history is irrelevant here
thank you!
i find it really offensive that someone answers with that attitude while i did my best the last 6 months to overthink my way of communication and contribute w ith a *lot of testing* and bug-triage in context encryption/security which took *a lot* of time, many hours of it in my worktime supported by the OK spend time for it of my employer to get this "new year greeting"
Sent from my Google Nexus 5 On Jan 2, 2014 8:36 AM, "Richard W.M. Jones" rjones@redhat.com wrote:
On Thu, Jan 02, 2014 at 04:28:59PM +0100, Reindl Harald wrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
Why did you even bother posting this message, if not to dismiss the hard work of people who actually do stuff, rather than spending all day trolling?
DNF is a planned replacement (some time in the future). Ales is quite correctly asking for feedback and opening things up to a wider userbase. Some things don't work, as he is aware.
Rich.
Aye. He is pretty on top of things in my experience with him.
I also don't see the point of this thread.
Dan
On Thu, Jan 2, 2014 at 7:28 AM, Reindl Harald h.reindl@thelounge.netwrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
and yes "yum remove kernel" is a *minimum* to handeled properly
there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines guess how abused they are if they have completly different behavior because dveleopers tend to call anything they don't like to implement a "border case"
Reindl makes a very good case here against the adoption. The last thing we want is to cause confusion in the community. It may be very wise to wait and give the community more time to absorb dnf. I confess that it would be a learning curve for me to use this command: I could imagine the headaches it would bring others with much more pressing deadlines.
my 2 cents,
Richard
On Thu, Jan 2, 2014 at 11:09 AM, Richard Vickery richard.vickeryrv@gmail.com wrote:
On Thu, Jan 2, 2014 at 7:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
and yes "yum remove kernel" is a *minimum* to handeled properly
there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines guess how abused they are if they have completly different behavior because dveleopers tend to call anything they don't like to implement a "border case"
Reindl makes a very good case here against the adoption. The last thing we want is to cause confusion in the community. It may be very wise to wait and give the community more time to absorb dnf. I confess that it would be a learning curve for me to use this command: I could imagine the headaches it would bring others with much more pressing deadlines.
my 2 cents,
I don't understand what the learning curve is? It works exactly the same as yum. Typing 'dnf' instead of 'yum' is a learning curve?
I'm confused.
Dan
On 01/02/2014 02:25 PM, Dan Mashal wrote:
On Thu, Jan 2, 2014 at 11:09 AM, Richard Vickery richard.vickeryrv@gmail.com wrote:
On Thu, Jan 2, 2014 at 7:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
and yes "yum remove kernel" is a *minimum* to handeled properly
there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines guess how abused they are if they have completly different behavior because dveleopers tend to call anything they don't like to implement a "border case"
Reindl makes a very good case here against the adoption. The last thing we want is to cause confusion in the community. It may be very wise to wait and give the community more time to absorb dnf. I confess that it would be a learning curve for me to use this command: I could imagine the headaches it would bring others with much more pressing deadlines.
my 2 cents,
I don't understand what the learning curve is? It works exactly the same as yum. Typing 'dnf' instead of 'yum' is a learning curve?
I'm confused.
Dan
If is a drop in replacement for yum - then why not call it yum, then there is "no" learning curve.
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
On 02.01.2014 20:36, Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
Did Not Finish Do Not Forget Does Not Follow Data Not Found Did Not Find Does Not Function Do Not Freeze Do Not Fix Do Not Fax Do Not Forward
poma
5 PM, poma pomidorabelisima@gmail.com wrote: On 02.01.2014 20:36, Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
Did Not Finish Do Not Forget Does Not Follow Data Not Found Did Not Find Does Not Function Do Not Freeze Do Not Fix Do Not Fax Do Not Forward
poma
I do not think it is nice to speak so bad about a project. The objective are clear,if something can be improved everyone can or must contribute.The criticisms are useless.We are talking about open source software, do not forget.
Best regards
-- 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 Thu, Jan 2, 2014 at 3:28 PM, yersinia yersinia.spiros@gmail.com wrote:
5 PM, poma pomidorabelisima@gmail.com wrote: On 02.01.2014 20:36, Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified -
as opposed to being some
nonsensical conglomeration of letters. The only thing I am aware of
that dnf means is "did not finish".
Did Not Finish Do Not Forget Does Not Follow Data Not Found Did Not Find Does Not Function Do Not Freeze Do Not Fix Do Not Fax Do Not Forward
poma
I do not think it is nice to speak so bad about a project. The objective are clear,if something can be improved everyone can or must contribute.The criticisms are useless.We are talking about open source software, do not forget.
Best regards
On the contrary: speaking negatively about a project may be fine so long as the context is clearly about such project, as it is only the project that is being harshly criticised. Where a problem often occurs is when such criticism crosses over into affecting an individual.
On 01/02/2014 04:36 PM, Richard Vickery wrote:
On Thu, Jan 2, 2014 at 3:28 PM, yersinia <yersinia.spiros@gmail.com mailto:yersinia.spiros@gmail.com> wrote:
>5 PM, poma <pomidorabelisima@gmail.com <mailto:pomidorabelisima@gmail.com>> wrote: > On 02.01.2014 20:36, Steve Clark wrote: > >> Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some >> nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish". > > Did Not Finish > Do Not Forget > <..snip..>
> > poma I do not think it is nice to speak so bad about a project. The objective are clear,if something can be improved everyone can or must contribute.The criticisms are useless.We are talking about open source software, do not forget. Best regards >On the contrary: speaking negatively about a project may be fine so long as the context is clearly about such project, as it is only the project that is being harshly criticised. Where a problem often occurs is when such criticism crosses over into affecting an individual.
From the fedoraproject.org wiki: "Note about the name "DNF": it has no relevant meaning, meant as a project name only" It seems rather unfortunate that as a random collection of letters, DNF currently has primarily negative connotations: http://en.wikipedia.org/wiki/DNF http://www.urbandictionary.com/define.php?term=DNF https://www.google.com/#q=dnf
As a runner, DNF already has a specific meaning for me. If you're picking random letters for a project to avoid existing collisions, you might also consider tossing the set back into the bag they have a well-established meaning in other domains. Just saying - it might do well to change the name to something with positive or at least neutral collateral meaning. "yum" probably had some positive benefits in this regard.
Cheers, -Bob Arendt
On 03.01.2014 01:06, Bob Arendt wrote:
As a runner, DNF already has a specific meaning for me. If you're picking random letters for a project to avoid existing collisions, you might also consider tossing the set back into the bag they have a well-established meaning in other domains. Just saying - it might do well to change the name to something with positive or at least neutral collateral meaning. "yum" probably had some positive benefits in this regard.
"Yum" has sentimental value and is practically a trademark, so 1. yuma - Yellowdog Updater, Modified Again 2. yum2 - Yellowdog Updater, Modified II 3. yumrelo - Yellowdog Updater, Modified Reloaded 6. yum-ng - Yellowdog Updater, Modified NG (Next Generation) 5. yum-ak - Yellowdog Updater, Modified AK (Ales Kozumplik) 4. yum-novus - Yellowdog Updater, Modified New 7. yummy - Yellowdog Updater, Modified My
poma
On Fri, Jan 03, 2014 at 02:18:52AM +0100, poma wrote:
On 03.01.2014 01:06, Bob Arendt wrote:
As a runner, DNF already has a specific meaning for me. If you're picking random letters for a project to avoid existing collisions, you might also consider tossing the set back into the bag they have a well-established meaning in other domains. Just saying - it might do well to change the name to something with positive or at least neutral collateral meaning. "yum" probably had some positive benefits in this regard.
"Yum" has sentimental value and is practically a trademark, so
- yuma - Yellowdog Updater, Modified Again
- yum2 - Yellowdog Updater, Modified II
- yumrelo - Yellowdog Updater, Modified Reloaded
- yum-ng - Yellowdog Updater, Modified NG (Next Generation)
- yum-ak - Yellowdog Updater, Modified AK (Ales Kozumplik)
- yum-novus - Yellowdog Updater, Modified New
- yummy - Yellowdog Updater, Modified My
How about:
fu - Fedora Updater. fum - Fedora Updater, Modified.
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
Or, we can just forget about any connotation, like apparently we did when coming up with "fedup".
On Thu, Jan 2, 2014 at 5:28 PM, Chuck Anderson cra@wpi.edu wrote:
On Fri, Jan 03, 2014 at 02:18:52AM +0100, poma wrote:
On 03.01.2014 01:06, Bob Arendt wrote:
As a runner, DNF already has a specific meaning for me. If you're picking random letters for a project to avoid existing collisions, you might also consider tossing the set back into the bag they have a well-established meaning in other domains. Just saying - it might do well to change the name to something with positive or at least neutral collateral meaning. "yum" probably had some positive benefits in this regard.
"Yum" has sentimental value and is practically a trademark, so
- yuma - Yellowdog Updater, Modified Again
- yum2 - Yellowdog Updater, Modified II
- yumrelo - Yellowdog Updater, Modified Reloaded
- yum-ng - Yellowdog Updater, Modified NG (Next Generation)
- yum-ak - Yellowdog Updater, Modified AK (Ales Kozumplik)
- yum-novus - Yellowdog Updater, Modified New
- yummy - Yellowdog Updater, Modified My
How about:
fu - Fedora Updater. fum - Fedora Updater, Modified.
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
Or, we can just forget about any connotation, like apparently we did when coming up with "fedup".
LOL - Is this supposed to be a play on words / accronyms?
On 03.01.2014 02:31, Richard Vickery wrote:
On Thu, Jan 2, 2014 at 5:28 PM, Chuck Anderson cra@wpi.edu wrote:
On Fri, Jan 03, 2014 at 02:18:52AM +0100, poma wrote:
On 03.01.2014 01:06, Bob Arendt wrote:
As a runner, DNF already has a specific meaning for me. If you're picking random letters for a project to avoid existing collisions, you might also consider tossing the set back into the bag they have a well-established meaning in other domains. Just saying - it might do well to change the name to something with positive or at least neutral collateral meaning. "yum" probably had some positive benefits in this regard.
"Yum" has sentimental value and is practically a trademark, so
- yuma - Yellowdog Updater, Modified Again
- yum2 - Yellowdog Updater, Modified II
- yumrelo - Yellowdog Updater, Modified Reloaded
- yum-ng - Yellowdog Updater, Modified NG (Next Generation)
- yum-ak - Yellowdog Updater, Modified AK (Ales Kozumplik)
- yum-novus - Yellowdog Updater, Modified New
- yummy - Yellowdog Updater, Modified My
How about:
fu - Fedora Updater. fum - Fedora Updater, Modified.
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
Or, we can just forget about any connotation, like apparently we did when coming up with "fedup".
LOL - Is this supposed to be a play on words / accronyms?
Haha, actually pretty cool! 0. yum-fu - Yellowdog Updater, Modified Fu (No need to explain)
poma
On Fri, Jan 03, 2014 at 02:40:33AM +0100, poma wrote:
On 03.01.2014 02:31, Richard Vickery wrote:
On Thu, Jan 2, 2014 at 5:28 PM, Chuck Anderson cra@wpi.edu wrote:
On Fri, Jan 03, 2014 at 02:18:52AM +0100, poma wrote:
On 03.01.2014 01:06, Bob Arendt wrote:
As a runner, DNF already has a specific meaning for me. If you're picking random letters for a project to avoid existing collisions, you might also consider tossing the set back into the bag they have a well-established meaning in other domains. Just saying - it might do well to change the name to something with positive or at least neutral collateral meaning. "yum" probably had some positive benefits in this regard.
"Yum" has sentimental value and is practically a trademark, so
- yuma - Yellowdog Updater, Modified Again
- yum2 - Yellowdog Updater, Modified II
- yumrelo - Yellowdog Updater, Modified Reloaded
- yum-ng - Yellowdog Updater, Modified NG (Next Generation)
- yum-ak - Yellowdog Updater, Modified AK (Ales Kozumplik)
- yum-novus - Yellowdog Updater, Modified New
- yummy - Yellowdog Updater, Modified My
How about:
fu - Fedora Updater. fum - Fedora Updater, Modified.
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
Or, we can just forget about any connotation, like apparently we did when coming up with "fedup".
LOL - Is this supposed to be a play on words / accronyms?
Haha, actually pretty cool! 0. yum-fu - Yellowdog Updater, Modified Fu (No need to explain)
poma
Or to be more generic about it:
pu - Package Updater. pum - Package Updater, Modified. puma - Package Updater, Modified Again. poma - Package Opener (Operator?), Modified Again
That last one is tounge-in-cheek :-J
On 01/02/2014 06:52 PM, Chuck Anderson wrote:
On Fri, Jan 03, 2014 at 02:40:33AM +0100, poma wrote:
On 03.01.2014 02:31, Richard Vickery wrote:
On Thu, Jan 2, 2014 at 5:28 PM, Chuck Anderson cra@wpi.edu wrote:
On Fri, Jan 03, 2014 at 02:18:52AM +0100, poma wrote:
On 03.01.2014 01:06, Bob Arendt wrote:
As a runner, DNF already has a specific meaning for me. If you're picking random letters for a project to avoid existing collisions, you might also consider tossing the set back into the bag they have a well-established meaning in other domains. Just saying - it might do well to change the name to something with positive or at least neutral collateral meaning. "yum" probably had some positive benefits in this regard.
"Yum" has sentimental value and is practically a trademark, so
- yuma - Yellowdog Updater, Modified Again
- yum2 - Yellowdog Updater, Modified II
- yumrelo - Yellowdog Updater, Modified Reloaded
- yum-ng - Yellowdog Updater, Modified NG (Next Generation)
- yum-ak - Yellowdog Updater, Modified AK (Ales Kozumplik)
- yum-novus - Yellowdog Updater, Modified New
- yummy - Yellowdog Updater, Modified My
How about:
fu - Fedora Updater. fum - Fedora Updater, Modified.
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
Or, we can just forget about any connotation, like apparently we did when coming up with "fedup".
LOL - Is this supposed to be a play on words / accronyms?
Haha, actually pretty cool! 0. yum-fu - Yellowdog Updater, Modified Fu (No need to explain)
poma
Or to be more generic about it:
pu - Package Updater. pum - Package Updater, Modified. puma - Package Updater, Modified Again. poma - Package Opener (Operator?), Modified Again
That last one is tounge-in-cheek :-J
puma ! Similar to orig name (continuity), "p" for package (better than yellow-dog), and humorous extension "a" that turns it into a word with logo possibilities. And shouldn't have brand overlap with the shoes (they're going with the animal association anyway). You could get some some traction with that name.
-Bob
Chuck Anderson wrote:
How about:
fu - Fedora Updater. fum - Fedora Updater, Modified.
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
Maybe to you… To me, it means either "F… You!" or just "FU**". ^^
"FUBAR" also comes to my mind.
Really, it's not that great a name!
Kevin Kofler
On 03.01.2014 02:28, Chuck Anderson wrote:
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
poma
Am 03.01.2014 03:54, schrieb poma:
On 03.01.2014 02:28, Chuck Anderson wrote:
fu has a positive connotation: "fu, a particle or suffix that can mean "intensity" [1].
*please* stop this useless joke-posts damaging any technical discussion there are two people (including you) commentig *any* thread with joke posts or some "LoL" with no value to the discussion
thank you!
On Thu, Jan 2, 2014 at 8:18 PM, poma pomidorabelisima@gmail.com wrote:
"Yum" has sentimental value and is practically a trademark, so
- yuma - Yellowdog Updater, Modified Again
- yum2 - Yellowdog Updater, Modified II
- yumrelo - Yellowdog Updater, Modified Reloaded
- yum-ng - Yellowdog Updater, Modified NG (Next Generation)
- yum-ak - Yellowdog Updater, Modified AK (Ales Kozumplik)
- yum-novus - Yellowdog Updater, Modified New
- yummy - Yellowdog Updater, Modified My
yummy has a has a certain je ne sais quoi about it for me. But maybe "did not finish" is not a bad backronym either. Like is some software ever really finished?
Date: Thu, 2 Jan 2014 15:36:11 -0800 Subject: Re: dnf versus yum From: richard.vickeryrv@gmail.com To: devel@lists.fedoraproject.org
On Thu, Jan 2, 2014 at 3:28 PM, yersinia yersinia.spiros@gmail.com wrote:
5 PM, poma pomidorabelisima@gmail.com wrote:
On 02.01.2014 20:36, Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some
nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
Did Not Finish
Do Not Forget
Does Not Follow
Data Not Found
Did Not Find
Does Not Function
Do Not Freeze
Do Not Fix
Do Not Fax
Do Not Forward
poma
I do not think it is nice to speak so bad about a project. The
objective are clear,if something can be improved everyone can or must
contribute.The criticisms are useless.We are talking about open source
software, do not forget. 👍I agree
Best regards
On the contrary: speaking negatively about a project may be fine so long as the context is clearly about such project, as it is only the project that is being harshly criticised. Where a problem often occurs is when such criticism crosses over into affecting an individual.
On 03.01.2014 00:28, yersinia wrote:
I do not think it is nice to speak so bad about a project. The objective are clear,if something can be improved everyone can or must contribute.The criticisms are useless.We are talking about open source software, do not forget.
"…, do not forget." :)
poma
2014-01-02 21:15 keltezéssel, poma írta:
On 02.01.2014 20:36, Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
Did Not Finish Do Not Forget Does Not Follow Data Not Found Did Not Find Does Not Function Do Not Freeze Do Not Fix Do Not Fax Do Not Forward
Duke Nukem Forever, with all the implications of promised and shipping date... ;-)
poma
Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
The point of this thread is that the development apparently indeed Did Not Finish. ;-)
Kevin Kofler
On Fri, 2014-01-03 at 02:48 +0100, Kevin Kofler wrote:
Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
The point of this thread is that the development apparently indeed Did Not Finish. ;-)
And it's an astoundingly pointless point, given that it was prompted by a post from its developer asking people to test it ahead of it being *potentially* included in Fedora as the default package manager *in more than a year's time*.
Clearly, he knows it isn't ready to replace yum yet. If he thought it was, he'd be filing a Change to replace yum with dnf, not writing a blog post trying to get slightly wider testing.
This is possibly the most useless thread I've ever seen on devel@, and that's some strong competition.
Am 03.01.2014 08:17, schrieb Adam Williamson:
On Fri, 2014-01-03 at 02:48 +0100, Kevin Kofler wrote:
Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
The point of this thread is that the development apparently indeed Did Not Finish. ;-)
And it's an astoundingly pointless point, given that it was prompted by a post from its developer asking people to test it ahead of it being *potentially* included in Fedora as the default package manager *in more than a year's time*.
Clearly, he knows it isn't ready to replace yum yet. If he thought it was, he'd be filing a Change to replace yum with dnf, not writing a blog post trying to get slightly wider testing.
the point where the statements what DNF all does not need and not that it is not yet written, the point is that he meant it is not needed at all
that's a bad attitude for somebody going out to replace perfectly working software over the time
This is possibly the most useless thread I've ever seen on devel@, and that's some strong competition
that must be why while this thread was running "keep_cache" started to come back https://bugzilla.redhat.com/show_bug.cgi?id=1046244
be careful with the word "useless" - you may be the same way wrong as *many* developers are wrong with their assumptions about real world usecases
the only useless in this thread are some funny guys making funny posts about names instead be quiet in case they have nothing to say
On Fri, Jan 03, 2014 at 02:54:04PM +0100, Reindl Harald wrote:
Am 03.01.2014 08:17, schrieb Adam Williamson:
On Fri, 2014-01-03 at 02:48 +0100, Kevin Kofler wrote:
Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
The point of this thread is that the development apparently indeed Did Not Finish. ;-)
And it's an astoundingly pointless point, given that it was prompted by a post from its developer asking people to test it ahead of it being *potentially* included in Fedora as the default package manager *in more than a year's time*.
Clearly, he knows it isn't ready to replace yum yet. If he thought it was, he'd be filing a Change to replace yum with dnf, not writing a blog post trying to get slightly wider testing.
the point where the statements what DNF all does not need and not that it is not yet written, the point is that he meant it is not needed at all
that's a bad attitude for somebody going out to replace perfectly working software over the time
This is possibly the most useless thread I've ever seen on devel@, and that's some strong competition
that must be why while this thread was running "keep_cache" started to come back https://bugzilla.redhat.com/show_bug.cgi?id=1046244
be careful with the word "useless" - you may be the same way wrong as *many* developers are wrong with their assumptions about real world usecases
the only useless in this thread are some funny guys making funny posts about names instead be quiet in case they have nothing to say
I apologize for making this thread perceived to be useless by my remarks on dnf naming. I think this is an important thread and agree with most of the issues reported with dnf as it currently stands. I think it is important to bring up these issues now, a year in advance, especially since that is exactly what was asked by the dnf developer.
But I also think naming is important, and that gratuitous renaming of an important piece of user-visible software functionality that makes up part of the sysadmin's user interface should be avoided without good reason, and more thought should be put into changing this user interface if it is deemed necessary or desirable. Names matter, and using more generic names or names that at least have some recognizable meaning facilitates the learning curve and understanding of the proposed change.
Do we really want to create a Fedora-specific arcane lore of command names that are hard to remember, or would the project and larger Linux community as a whole be better served by a command-line user interface that makes some logical sense? Don't you think people would have objected if systemd was called "gharvakjs" instead? Or if the systemctl command was called "uirweun"? Or if someone came along and decided to make a better "ls" command but called it "vb" instead? While these are absurd examples, it does illustrate why naming is important.
HI
On Fri, Jan 3, 2014 at 12:32 PM, Chuck Anderson wrote:
But I also think naming is important, and that gratuitous renaming of an important piece of user-visible software functionality that makes up part of the sysadmin's user interface should be avoided without good reason,
My understanding is that dnf is only the name of the "experimental fork" of yum and the end result will continue to be called yum. Am I wrong about that?
Rahul
On Fri, Jan 3, 2014 at 1:55 PM, Rahul Sundaram metherid@gmail.com wrote:
My understanding is that dnf is only the name of the "experimental fork" of yum and the end result will continue to be called yum. Am I wrong about that?
That was my understand as well (as of about a year ago), but I don't know if that's still the current plan or not.
-- Jared Smith
On Fri, 3 Jan 2014 15:33:43 -0500 "Jared K. Smith" jsmith@fedoraproject.org wrote:
That was my understand as well (as of about a year ago), but I don't know if that's still the current plan or not.
-- Jared Smith
Do you mean dnf will obsolete yum In that "dnf will be called yum" If so, can it be extended beyond F22ish if necessary. To allow Ales (+team), maybe have time to take on board any feedback?
___ Regards, Frank www.frankly3d.com
Hi
On Sat, Jan 4, 2014 at 3:03 AM, Frank Murphy wrote:
Do you mean dnf will obsolete yum In that "dnf will be called yum" If so, can it be extended beyond F22ish if necessary. To allow Ales (+team), maybe have time to take on board any feedback?
dnf was originally introduced in Fedora 18 and the plan as proposed then was for dnf to replace yum by Fedora 22. So we have some time left for feedback and correct those issues and reevaluate as we get close to the development feature planning stage of that release. I have already been testing all this time and filed probably the most number of reports, many of them fixed already. You are also in the bug report that Ales agreed to add back keepcache
https://bugzilla.redhat.com/show_bug.cgi?id=1046244#c2
From my perspective, there are the following issues that needs to be fixed
before that replacement can happen
* delta RPM support (https://bugzilla.redhat.com/show_bug.cgi?id=909468) * bash completion (https://bugzilla.redhat.com/show_bug.cgi?id=1030440) * drop deprecated aliases ( https://bugzilla.redhat.com/show_bug.cgi?id=963343) * autoremove (plugin) (https://bugzilla.redhat.com/show_bug.cgi?id=963345) * name only search (https://bugzilla.redhat.com/show_bug.cgi?id=963140) * protected packages functionality (unfiled?) * yum remove kernel vs dnf remove kernel difference (unfiled? )
yum utilities
* yum-builddep (https://bugzilla.redhat.com/show_bug.cgi?id=905697) * yumdownloader (https://bugzilla.redhat.com/show_bug.cgi?id=1045679) * debuginfo-install (https://bugzilla.redhat.com/show_bug.cgi?id=1045770) * repoquery (https://bugzilla.redhat.com/show_bug.cgi?id=1045078) * yum-config-manager (filed but rejected at https://bugzilla.redhat.com/show_bug.cgi?id=1044984)
Hope that helps
Rahul
On 01/04/2014 08:56 PM, Rahul Sundaram wrote:
- yum remove kernel vs dnf remove kernel difference (unfiled? )
I found 976704, closed with 'Resolution: --- → UPSTREAM' in August. Not sure what that means, but removing all kernels seem a bit odd and at least the running kernel should be spared, in my opinion.
https://bugzilla.redhat.com/show_bug.cgi?id=976704
Lars
On 2014-01-04 21:31, Lars E. Pettersson wrote:
On 01/04/2014 08:56 PM, Rahul Sundaram wrote:
- yum remove kernel vs dnf remove kernel difference (unfiled? )
I found 976704, closed with 'Resolution: --- → UPSTREAM' in August. Not sure what that means, but removing all kernels seem a bit odd and at least the running kernel should be spared, in my opinion.
https://bugzilla.redhat.com/show_bug.cgi?id=976704
Lars
Hej...
Well, a lot of other (most?) folks have the same opinion - have a look in the archives for this thread....
--alec
On Sat, 2014-01-04 at 21:41 +0100, Alec Leamas wrote:
On 2014-01-04 21:31, Lars E. Pettersson wrote:
On 01/04/2014 08:56 PM, Rahul Sundaram wrote:
- yum remove kernel vs dnf remove kernel difference (unfiled? )
I found 976704, closed with 'Resolution: --- → UPSTREAM' in August. Not sure what that means, but removing all kernels seem a bit odd and at least the running kernel should be spared, in my opinion.
https://bugzilla.redhat.com/show_bug.cgi?id=976704
Lars
Hej...
Well, a lot of other (most?) folks have the same opinion - have a look in the archives for this thread....
It's a bit hard to tell, but from the comment it looks like it was really closed as 'notabug' rather than 'upstream'.
Il 05/01/2014 00:13, Adam Williamson ha scritto:
On Sat, 2014-01-04 at 21:41 +0100, Alec Leamas wrote:
On 2014-01-04 21:31, Lars E. Pettersson wrote:
On 01/04/2014 08:56 PM, Rahul Sundaram wrote:
- yum remove kernel vs dnf remove kernel difference (unfiled? )
I found 976704, closed with 'Resolution: --- → UPSTREAM' in August. Not sure what that means, but removing all kernels seem a bit odd and at least the running kernel should be spared, in my opinion.
https://bugzilla.redhat.com/show_bug.cgi?id=976704
Lars
Hej...
Well, a lot of other (most?) folks have the same opinion - have a look in the archives for this thread....
It's a bit hard to tell, but from the comment it looks like it was really closed as 'notabug' rather than 'upstream'.
They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Am 05.01.2014 09:23, schrieb Mattia Verga:
Il 05/01/2014 00:13, Adam Williamson ha scritto:
On Sat, 2014-01-04 at 21:41 +0100, Alec Leamas wrote:
On 2014-01-04 21:31, Lars E. Pettersson wrote:
On 01/04/2014 08:56 PM, Rahul Sundaram wrote:
- yum remove kernel vs dnf remove kernel difference (unfiled? )
I found 976704, closed with 'Resolution: --- → UPSTREAM' in August. Not sure what that means, but removing all kernels seem a bit odd and at least the running kernel should be spared, in my opinion.
https://bugzilla.redhat.com/show_bug.cgi?id=976704
Lars
Hej...
Well, a lot of other (most?) folks have the same opinion - have a look in the archives for this thread....
It's a bit hard to tell, but from the comment it looks like it was really closed as 'notabug' rather than 'upstream'.
They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
and that is clearly a regression
how likely is that somebody want to delete all kernels include the running one? "the user can always specify concrete versions on the command line" - yes, at the same time the user can "rpm -e --nodeps" if he really knwos what he is doing
the same for:
protected_packages is ignored DNF drops Yum’s protected_packages configuration option. Generally, DNF lets the user do what she specified, even have DNF itself removed. Similar functionality can be implemented by a plugin
"DNF lets the user do what she specified" is nonsense, the system must not destroy itself without *explicitly* specified this action via a *non-default* switch
Am 05.01.2014 09:40, schrieb Reindl Harald:
They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
and that is clearly a regression
how likely is that somebody want to delete all kernels include the running one? "the user can always specify concrete versions on the command line" - yes, at the same time the user can "rpm -e --nodeps" if he really knwos what he is doing
the same for:
protected_packages is ignored DNF drops Yum’s protected_packages configuration option. Generally, DNF lets the user do what she specified, even have DNF itself removed. Similar functionality can be implemented by a plugin
"DNF lets the user do what she specified" is nonsense, the system must not destroy itself without *explicitly* specified this action via a *non-default* switch
the following paragraph would only be true if the UsrMove would have been finished which is not the case, otherwise i would not be forced to carry a meta-apckage with "Provides: %{_sbindir}/ldconfig" even in F20 because all my self-maintained packages have done UsrMove
i had this fun recently by upgrade to F20 with yum because for dependency solving the metapackage was temporarly removed and there are still issues if glibc and other packages are updated at the same time
so for me there are two choices:
* finish UsrMove and stop refer to /bin and /sbin anywhere in the distribution * let DNF not assume a finished UsrMove ______________________________
dnf provides /bin/<file> does not find any packages on Fedora
After UsrMove there’s no directory /bin on Fedora systems and no files get installed there, /bin is only a symlink created by the filesystem package to point to /usr/bin. Resolving the symlinks to their real path would only give the user false sense that this works while in fact provides requests using globs such as
On 01/05/2014 09:23 AM, Mattia Verga wrote:
They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Yes, I have read that, but (strongly) disagree.
The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?), a better solution would be to safe guard the running kernel, only removing it if you explicitly ask for it:
$ uname -a Linux tux 3.12.6-300.fc20.x86_64 #1 SMP Mon Dec 23 16:44:31 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ dnf erase kernel-3.12.6-300.fc20.x86_64
The same thing could be said about other packages now protected in yum. Please protect them in the same way in dnf.
Lars
On Sun, Jan 5, 2014 at 10:27 AM, Lars E. Pettersson lars@homer.se wrote:
On 01/05/2014 09:23 AM, Mattia Verga wrote:
why did they change remove into erase?
Yum actually offers both erase and remove for the same purpose. I don't know which is an alias of the other, but rpm uses erase.
From the man page: rpm {-e|--erase}
Lars
Lars E. Pettersson lars@homer.se http://www.sm6rpz.se/ -- 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 01/05/2014 12:02 PM, Dridi Boukelmoune wrote:
On Sun, Jan 5, 2014 at 10:27 AM, Lars E. Pettersson lars@homer.se wrote:
On 01/05/2014 09:23 AM, Mattia Verga wrote:
why did they change remove into erase?
Yum actually offers both erase and remove for the same purpose. I don't know which is an alias of the other, but rpm uses erase.
From the man page: rpm {-e|--erase}
Ah, did not know that, if you try to auto complete yum only remove shows up, but erase also works. So perhaps erase was an afterthought, to mimic the rpm behavior. If rpm has erase, and yum also can use erase, perhaps erase is the way to go, perhaps...? :)
Lars
On Sun, 05 Jan 2014 12:16:36 +0100 "Lars E. Pettersson" lars@homer.se wrote:
Ah, did not know that, if you try to auto complete yum only remove shows up, but erase also works. So perhaps erase was an afterthought, to mimic the rpm behavior. If rpm has erase, and yum also can use erase, perhaps erase is the way to go, perhaps...? :)
Lars
Maybe remove was for @debian people used to "apt-get remove"?
___ Regards, Frank www.frankly3d.com
Am 05.01.2014 12:21, schrieb Frank Murphy:
On Sun, 05 Jan 2014 12:16:36 +0100 "Lars E. Pettersson" lars@homer.se wrote:
Ah, did not know that, if you try to auto complete yum only remove shows up, but erase also works. So perhaps erase was an afterthought, to mimic the rpm behavior. If rpm has erase, and yum also can use erase, perhaps erase is the way to go, perhaps...? :)
Maybe remove was for @debian people used to "apt-get remove"?
and if developers would be more pragmatic and user-friendly this wouöd not be discussed a single second and both supported
the time which was used to explain why could have been used for implement the alias
why? "why not?" should be the real question
both are clear words and if both are supported it would not matter if "erase" is logical for user A or "remove" for user B
On Sun, 2014-01-05 at 12:34 +0100, Reindl Harald wrote:
Am 05.01.2014 12:21, schrieb Frank Murphy:
On Sun, 05 Jan 2014 12:16:36 +0100 "Lars E. Pettersson" lars@homer.se wrote:
Ah, did not know that, if you try to auto complete yum only remove shows up, but erase also works. So perhaps erase was an afterthought, to mimic the rpm behavior. If rpm has erase, and yum also can use erase, perhaps erase is the way to go, perhaps...? :)
Maybe remove was for @debian people used to "apt-get remove"?
and if developers would be more pragmatic and user-friendly this wouöd not be discussed a single second and both supported
You're losing track of the discussion. This has devolved into a sub-thread about the commands 'remove' and 'erase', it now has little to do with the call about what '[yum/dnf] [remove/erase] kernel' should do.
On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote:
On 01/05/2014 09:23 AM, Mattia Verga wrote:
They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Yes, I have read that, but (strongly) disagree.
The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?),
They didn't. Both work on both.
On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote:
On 01/05/2014 09:23 AM, Mattia Verga wrote:
They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Yes, I have read that, but (strongly) disagree.
The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?),
They didn't. Both work on both.
It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs.
Am 05.01.2014 19:07, schrieb Adam Williamson:
On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote:
On 01/05/2014 09:23 AM, Mattia Verga wrote:
They really want to make dnf work this way. This is explained here: http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Yes, I have read that, but (strongly) disagree.
The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?),
They didn't. Both work on both.
It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
*that* and other things missing are example why this thread is not terrible or useless and as you have seen the cache is coming back which was declared as "useless" by DNF developers before this discussion
honestly i am *not* testing DNF *because currently* it lacks obviously features which makes it a no-go replacement for my envirnonments and *the main reason* for this thread was push it in a direction where it makes sense for me to have it on my testserver, even risk a dist-upgrade on a VM and give feeback/karma for updates - as said - ASAP and not too late to get things fine before it really claims to replace YUM
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Frankly, that's a dumb "feature" to have the package manager know "magic" things about some names. Why is it dumb? Because some people then depend on magic "features". Is this "feature" even documented anywhere? I don't see it in the yum man page for example.
I never knew that "yum erase kernel" wouldn't actually remove all packages named "kernel", because I would never say "erase the kernel" and expect something to not erase the kernel. It could be correct to erase all installed kernel packages, for example on a VM where booting is external to the VM. Or, maybe you want to re-install the kernel package to fix something such as a file getting deleted accidentally (which "yum reinstall" is documented to not handle).
This is Unix; system programs are expected to "do what I say". Don't try to code "do what I mean" into it (because what you mean is probably different from what I mean).
We've had kernel variant packages in the past, like kernel-smp and kernel-PAE; are all variants supposed to be handled magically? What if there's a new variant? Would not handling it in the package manager magic be a release-blocker bug?
If you want a "dnf remove-all-but-some-magic-version kernel" option, write it in a plugin and install it on your systems. Or expect the program to do what you say; for example, if I wanted to remove all kernels except the running one, I'd do (from a saved management script, where I did want to remove all but the running kernel on a bunch of systems):
yum remove $(rpm -q --qf '%{version}-%{release}.%{arch}\n' kernel | while read k; do [ $k = $(uname -r) ] || echo "kernel-$k"; done)
Like I said, I never would have thought to just do "yum remove kernel" and expect yum to have magic undocumented behavior to save me.
To make such a "show-stopper" big deal about such a minor and undocumented "feature" is just wrong.
Am 05.01.2014 20:06, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Frankly, that's a dumb "feature" to have the package manager know "magic" things about some names. Why is it dumb? Because some people then depend on magic "features". Is this "feature" even documented anywhere? I don't see it in the yum man page for example. I never knew that "yum erase kernel" wouldn't actually remove all packages named "kernel", because I would never say "erase the kernel" and expect something to not erase the kernel.
others did because the tried what things are doing
This is Unix; system programs are expected to "do what I say". Don't try to code "do what I mean" into it (because what you mean is probably different from what I mean)
i say the same thing to the autopager and cutted output of systemctl and journalctl and the repsonse there is "we are not Unix, we are Linux"
so somewhere in time Fedora should decide if it follows the unix-way or not, there are many decisions helping endusers where i would say a technican "don't do that" and nobody cares
so in case of destory the system *yes* protect from happen it and allow to do with force flags but not by accident _________________________________
following your argumentation this should be removed too?
[root@honeypot:~]$ rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
i say the same thing to the autopager and cutted output of systemctl and journalctl and the repsonse there is "we are not Unix, we are Linux"
Yeah, I dislike that as well. If I want paged output, I'll page it; if I want cut output, I'll cut it. The "helpful" options added to the $PAGER variable are really stupid as well; I have to set $SYSTEMD_PAGER as well as $PAGER, just to override systemd's "help".
following your argumentation this should be removed too?
[root@honeypot:~]$ rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe
I didn't know that was there (not in the habit of running "rm -rf /" just to see what happens). I really can't think of a situation where "rm -rf /" would be useful, so I don't really care one way or the other about that one.
Am 05.01.2014 23:33, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
i say the same thing to the autopager and cutted output of systemctl and journalctl and the repsonse there is "we are not Unix, we are Linux"
Yeah, I dislike that as well. If I want paged output, I'll page it; if I want cut output, I'll cut it. The "helpful" options added to the $PAGER variable are really stupid as well; I have to set $SYSTEMD_PAGER as well as $PAGER, just to override systemd's "help".
agreed
but realize the lernel is a very special package following your argumentation it would be handeled as any other apckage and you would have not way to boot the old one if boot fails after a update
following your argumentation this should be removed too?
[root@honeypot:~]$ rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe
I didn't know that was there (not in the habit of running "rm -rf /" just to see what happens). I really can't think of a situation where "rm -rf /" would be useful, so I don't really care one way or the other about that one
where it would be useful? nowhere - press enter by accident while typing a command
where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state?
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state?
I already offered a couple of examples that you ignored (just a couple that came to mind, certainly not an exhaustive list): when you have a system that doesn't load a kernel from the filesystem, such as a VM environment where the boot process is external.
Another is if you need to re-install the kernel RPM because files have been removed, overwritten, etc.; "yum reinstall" is documented (unlike this magic "feature") to not handle multi-install packages like the kernel. The only way is going to be to "yum erase" and "yum install".
Also, even removing every kernel RPM will not render your system "non-recoverable". You can always use a boot CD, and in modern Fedora systems, the "rescue" kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that.
Am 05.01.2014 23:53, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state?
I already offered a couple of examples that you ignored (just a couple that came to mind, certainly not an exhaustive list): when you have a system that doesn't load a kernel from the filesystem, such as a VM environment where the boot process is external.
border cases where you can use --nodeps
Another is if you need to re-install the kernel RPM because files have been removed, overwritten, etc.; "yum reinstall" is documented (unlike this magic "feature") to not handle multi-install packages like the kernel. The only way is going to be to "yum erase" and "yum install".
this is *really* a border case where download and "rpm -Uvh --force" is the way to go
Also, even removing every kernel RPM will not render your system "non-recoverable". You can always use a boot CD, and in modern Fedora systems, the "rescue" kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that
you can do that, i can do that the ordianry user - i doubt
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
border cases where you can use --nodeps
What does --nodeps have to do with this?
this is *really* a border case where download and "rpm -Uvh --force" is the way to go
No, you should do it correctly. First, AFAIK rpm doesn't have the magic kernel behavior, so your "-U" will upgrade, not install, and you can't upgrade to the same package version (I don't think --force overrides that, but I haven't tried it myself). Second, --force should be banned from any recommended rpm usage; there is virtually never a good reason to do that (I haven't used it in many many years).
Also, even removing every kernel RPM will not render your system "non-recoverable". You can always use a boot CD, and in modern Fedora systems, the "rescue" kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that
you can do that, i can do that the ordianry user - i doubt
The "ordinary user" won't do "yum erase kernel" either, so that's moot. The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default).
In any case, this is still a very minor side issue, and should not derail practical dnf discussions.
Am 06.01.2014 02:12, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
border cases where you can use --nodeps
What does --nodeps have to do with this?
border cases are not usual behavior?
this is *really* a border case where download and "rpm -Uvh --force" is the way to go
No, you should do it correctly. First, AFAIK rpm doesn't have the magic kernel behavior, so your "-U" will upgrade, not install
ah and that is why yum/dnf should not have it too?
Also, even removing every kernel RPM will not render your system "non-recoverable". You can always use a boot CD, and in modern Fedora systems, the "rescue" kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that
you can do that, i can do that the ordianry user - i doubt
The "ordinary user" won't do "yum erase kernel" either, so that's moot
and *why* does it help *you* no longer support the long years existing behavior?
only because you did not know that it works instead put all kernels to uninstall explicit in the command line? have fun if you maintain more than 20 machines mixed of testing and production and after a few days you want them all at the same package level - currently it is one single command with zero danger
The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default).
In any case, this is still a very minor side issue, and should not derail practical dnf discussions
your practices? my practices?
"yum remove kernel" is a clean and sane way to remove all but not the running kernels "distribute-command.sh 'yum -y remove kernel'" is used here for years on a ton of machines
why do you think that a *replacement* should come up not support this? why do you think "we do not care and even allow remove dnf" is sane behavior?
hence that is why whatever calls itself a replacement for yum should *not* support destroy the running system without whatever *force switch*
On Mon, 2014-01-06 at 02:33 +0100, Reindl Harald wrote:
Am 06.01.2014 02:12, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
border cases where you can use --nodeps
What does --nodeps have to do with this?
border cases are not usual behavior?
His point was that there is nothing involving dependencies here. nodeps would not make any difference.
"yum remove kernel" is a clean and sane way to remove all but not the running kernels "distribute-command.sh 'yum -y remove kernel'" is used here for years on a ton of machines
On Mon, Jan 6, 2014 at 2:33 AM, Reindl Harald h.reindl@thelounge.net wrote:
Also, even removing every kernel RPM will not render your system "non-recoverable". You can always use a boot CD, and in modern Fedora systems, the "rescue" kernel/initramfs are never removed (not owned by any RPM), so you should always be able to boot that
you can do that, i can do that the ordianry user - i doubt
The "ordinary user" won't do "yum erase kernel" either, so that's moot
and *why* does it help *you* no longer support the long years existing behavior?
I am not involved in dnf development at all but maybe they want to have a clean code base without any hacks like this one? And just because something existed for years does not mean it has to be there forever (this one wasn't even documented at all).
only because you did not know that it works instead put all kernels to uninstall explicit in the command line? have fun if you maintain more than 20 machines mixed of testing and production and after a few days you want them all at the same package level - currently it is one single command with zero danger
package-cleanup --oldkernels --count 1
does the same for you.
On 01/05/2014 08:33 PM, Reindl Harald wrote:
"yum remove kernel" is a clean and sane way to remove all but not the running kernels "distribute-command.sh 'yum -y remove kernel'" is used here for years on a ton of machines
why do you think that a *replacement* should come up not support this? why do you think "we do not care and even allow remove dnf" is sane behavior?
hence that is why whatever calls itself a replacement for yum should *not* support destroy the running system without whatever *force switch*
I don't like the weird partial functionality of this feature. It is apparently undocumented---actually, it'd be tricky to document it because it seems to protect some nebulous set of system facilities (running kernel, current yum, presumably RPM and runtime libraries; probably also grub; what else?).
I actually agree that it makes sense to protect against deleting essential stuff built in, but an attempt should simply fail, just like trying to delete dependencies of existing packages, similarly to 'rm -rf /' requiring explicit '--no-preserve-root'.
Another point: it shouldn't be hardwired into the package manager but rather result from package properties. I can see several ways to do it: - an 'essentiality' property in the RPM file - a yum/dnf configuration file specifying a set of protected packages - a special, unremovable 'system' package that depends on kernel and dnf
Last two would be preferable, because they allow tailoring the set of protected packages differently for a datacenter server vs. a network appliance, desktop, etc.
On Wed, Jan 8, 2014 at 7:43 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
Another point: it shouldn't be hardwired into the package manager but rather result from package properties. I can see several ways to do it:
- an 'essentiality' property in the RPM file
- a yum/dnf configuration file specifying a set of protected packages
- a special, unremovable 'system' package that depends on kernel and dnf
YAGNI? Abstractions are useful only when we actually have a difference to abstract. (Perhaps we will have that difference with Fedora.next, but we don't seem to have it now.) Mirek
On Wed, Jan 08, 2014 at 01:43:01PM -0500, Przemek Klosowski wrote:
hence that is why whatever calls itself a replacement for yum should *not* support destroy the running system without whatever *force switch*
I don't like the weird partial functionality of this feature. It is apparently undocumented---actually, it'd be tricky to document it because it seems to protect some nebulous set of system facilities (running kernel, current yum, presumably RPM and runtime libraries; probably also grub; what else?).
I'm a little lost in the thread, but do you mean that yum's protected packages functionality is undocumented? If that is what you mean, check the man page. It says:
protected_packages This is a list of packages that yum should never completely remove. They are protected via Obsoletes as well as user/plugin removals.
The default is: yum glob:/etc/yum/protected.d/*.conf So any packages which should be protected can do so by including a file in /etc/yum/protected.d with their package name in it.
Also if this configuration is set to anything, then yum will protect the package corresponding to the running version of the kernel.
And on _my_ system, there's a /etc/yum/protected.d/systemd.conf containing owned by "systemd" and a gnome.conf containing gnome-shell which I think I put there myself. (Nothing owns it and I don't remember.)
This goes an amazingly long way toward protecting the system from accidental autophagy without really being all that complex.
Another point: it shouldn't be hardwired into the package manager but rather result from package properties. I can see several ways to do it:
- an 'essentiality' property in the RPM file
- a yum/dnf configuration file specifying a set of protected packages
- a special, unremovable 'system' package that depends on kernel and dnf
Option #2 it is.
Last two would be preferable, because they allow tailoring the set of protected packages differently for a datacenter server vs. a network appliance, desktop, etc.
Exactly. And configuration is better than a magic package.
Matthew Miller (mattdm@fedoraproject.org) said:
I'm a little lost in the thread, but do you mean that yum's protected packages functionality is undocumented? If that is what you mean, check the man page. It says:
protected_packages This is a list of packages that yum should never completely remove. They are protected via Obsoletes as well as user/plugin removals.
The default is: yum glob:/etc/yum/protected.d/*.conf So any packages which should be protected can do so by including a file in /etc/yum/protected.d with their package name in it.
Also if this configuration is set to anything, then yum will protect the package corresponding to the running version of the kernel.
While documented, I do find this last bit of behavior extremely odd and non-intuitive. (And hardcoded, no less.)
Bill
On Wed, Jan 08, 2014 at 02:56:14PM -0500, Bill Nottingham wrote:
Matthew Miller (mattdm@fedoraproject.org) said:
I'm a little lost in the thread, but do you mean that yum's protected packages functionality is undocumented? If that is what you mean, check the man page. It says:
protected_packages This is a list of packages that yum should never completely remove. They are protected via Obsoletes as well as user/plugin removals.
The default is: yum glob:/etc/yum/protected.d/*.conf So any packages which should be protected can do so by including a file in /etc/yum/protected.d with their package name in it.
Also if this configuration is set to anything, then yum will protect the package corresponding to the running version of the kernel.
While documented, I do find this last bit of behavior extremely odd and non-intuitive. (And hardcoded, no less.)
<nod> Just have yum drop a config file in there that protects the kernel rather than protecting the kernel if some other package chooses to protect something else.
-Toshio
Once upon a time, Toshio Kuratomi a.badger@gmail.com said:
<nod> Just have yum drop a config file in there that protects the kernel rather than protecting the kernel if some other package chooses to protect something else.
The magic "don't delete the running kernel" can't be done with just a config file. Something has to detect which kernel version is running and match it to an RPM, and then protect just that version of multiple installed kernel RPMs.
I supposed you could do it external to yum/dnf with a boot-time script that rewrites a config file to protect kernel-$(uname -r), but that may not always work (it would have to handle things like kernel-PAE and such).
Bill Nottingham wrote:
Matthew Miller (mattdm@fedoraproject.org) said:
I'm a little lost in the thread, but do you mean that yum's protected packages functionality is undocumented? If that is what you mean, check the man page. It says:
protected_packages This is a list of packages that yum should never completely remove. They are protected via Obsoletes as well as user/plugin removals.
The default is: yum glob:/etc/yum/protected.d/*.conf So any packages which should be protected can do so by including a file in /etc/yum/protected.d with their package name in it.
Also if this configuration is set to anything, then yum will protect the package corresponding to the running version of the kernel.
While documented, I do find this last bit of behavior extremely odd and non-intuitive. (And hardcoded, no less.)
There should just be a separate protect_running_kernel boolean option, which would default to the above odd behavior for compatibility if not set (but explicitly setting it to either 1 or 0 would override that either way).
Kevin Kofler
On Fri, Jan 10, 2014 at 1:04 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Bill Nottingham wrote:
Matthew Miller (mattdm@fedoraproject.org) said:
I'm a little lost in the thread, but do you mean that yum's protected packages functionality is undocumented? If that is what you mean, check the man page. It says:
protected_packages This is a list of packages that yum should never completely remove. They are protected via Obsoletes as well as user/plugin removals.
The default is: yum glob:/etc/yum/protected.d/*.conf So any packages which should be protected can do so by including a file in /etc/yum/protected.d with their package name in it.
Also if this configuration is set to anything, then yum will protect the package corresponding to the running version of the kernel.
While documented, I do find this last bit of behavior extremely odd and non-intuitive. (And hardcoded, no less.)
There should just be a separate protect_running_kernel boolean option, which would default to the above odd behavior for compatibility if not set (but explicitly setting it to either 1 or 0 would override that either way).
Can't the kernel package itself do that ?
I'm thinking about the %preun section (maybe %pretrans ?) where the package would know it's being removed, and could find out whether it's the running kernel.
One might also want to build a distribution on top of yum/rpm but choose a different name for the kernel package like "linux" or "linux-kernel".
Dridi
Kevin Kofler-- 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 Fri, Jan 10, 2014 at 2:50 PM, Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
On Fri, Jan 10, 2014 at 1:04 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Bill Nottingham wrote:
Matthew Miller (mattdm@fedoraproject.org) said:
I'm a little lost in the thread, but do you mean that yum's protected packages functionality is undocumented? If that is what you mean, check the man page. It says:
protected_packages This is a list of packages that yum should never completely remove. They are protected via Obsoletes as well as user/plugin removals.
The default is: yum glob:/etc/yum/protected.d/*.conf So any packages which should be protected can do so by including a file in /etc/yum/protected.d with their package name in it.
Also if this configuration is set to anything, then yum will protect the package corresponding to the running version of the kernel.
While documented, I do find this last bit of behavior extremely odd and non-intuitive. (And hardcoded, no less.)
There should just be a separate protect_running_kernel boolean option, which would default to the above odd behavior for compatibility if not set (but explicitly setting it to either 1 or 0 would override that either way).
Can't the kernel package itself do that ?
I'm thinking about the %preun section (maybe %pretrans ?) where the package would know it's being removed, and could find out whether it's the running kernel.
One might also want to build a distribution on top of yum/rpm but choose a different name for the kernel package like "linux" or "linux-kernel".
This reminds me that yum is built on top of rpm, and rpm doesn't mean linux. I remember my first time on AIX, and the surprising (yet unpleasant) fact that I had to use (a very old version of) rpm.
From rpm.org: RPM is a core component of many Linux distributions, such as Red Hat Enterprise Linux, the Fedora Project, SUSE Linux Enterprise, openSUSE, CentOS, Meego, Mageia and many others.
It is also used on many other operating systems as well
From rpm5.org: But RPM is also used for software packaging on many other Unix operating systems like FreeBSD, Sun OpenSolaris, IBM AIX and Apple Mac OS X through the cross-platform Unix software distribution OpenPKG.
I actually remember a comparison matrix of OpenSolaris forks, some of them chose /rpm5?/ for package management, but I can't find a link.
I do understand why people would want such features built-in, but it seems a bit short-sighted. And by short-sighted I don't mean a bad idea, I mean restricted to Fedora/RHEL and very close distributions. I don't know yum's goals, but the man page yum(8) and the faq don''t seem to mention any tight coupling to rhel-like linux distribution. Again, I'm not saying this would be a bad thing. AFAICT yum is tied *by essence* to rhel, but I'm also wondering what upstream thinks about portability, because the whole kernel issue is a portability no-no.
Dridi
Kevin Kofler-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Am 10.01.2014 16:49, schrieb Dridi Boukelmoune:
I actually remember a comparison matrix of OpenSolaris forks, some of them chose /rpm5?/ for package management, but I can't find a link.
I do understand why people would want such features built-in, but it seems a bit short-sighted. And by short-sighted I don't mean a bad idea, I mean restricted to Fedora/RHEL and very close distributions. I don't know yum's goals, but the man page yum(8) and the faq don''t seem to mention any tight coupling to rhel-like linux distribution. Again, I'm not saying this would be a bad thing. AFAICT yum is tied *by essence* to rhel, but I'm also wondering what upstream thinks about portability, because the whole kernel issue is a portability no-no
in that case the approach to have it as plugin is absolutely fine
* but this plugin should be available at the same time YUM is replaced by DNF * it should be in the default install
I only have a problem with "*could* be implemented" while try to replace something which *has* it implemented, this would be a step backwards from the users point of view insteda a improvement
not more, not less
On 5 January 2014 18:12, Chris Adams linux@cmadams.net wrote:
the ordianry user - i doubt
The "ordinary user" won't do "yum erase kernel" either, so that's moot. The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default).
Law of Out of Date Technical Support:
If an expert says "no ordinary user" would ever do a command, they have not worked front line Tech Support recently enough.
Ordinary people in the past have done this, and ordinary people in the future will do this. And it will be the same old tech support nightmare of handling it which will lead to eventually someone implementing a "Do you really want to do that" kind of fix. Since I routinely have to help people who do this I expect that it will be enough of an issue for Red Hat eventually to put in the extra logic again as it is expensive to deal with.
On Mon, 6 Jan 2014 12:38:46 -0700 Stephen John Smoogen smooge@gmail.com wrote:
If an expert says "no ordinary user" would ever do a command, they have not worked front line Tech Support recently enough.
<aside: but true> User- can you replace my modem, it doesn't work CSR: - can you do x,y,z . User: - No none work. CSR: Plug it in and out. User - Nope no good. CSR:- When was the last time you knew it was working User - Just before I threw it at the neighbours dog.
</aside>
___ Regards, Frank www.frankly3d.com
On Jan 6, 2014, at 12:38 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 5 January 2014 18:12, Chris Adams linux@cmadams.net wrote:
the ordianry user - i doubt
The "ordinary user" won't do "yum erase kernel" either, so that's moot. The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default).
Law of Out of Date Technical Support:
If an expert says "no ordinary user" would ever do a command, they have not worked front line Tech Support recently enough.
Sure. But I don't know how much hand holding with the CLI is practical and necessary. I can't tell you how many times I've done wipefs -a /dev/sdb, when I meant wipefs -a /dev/sdc because the f'n node ordering changed the drives around. I don't expect to be hand held through that, I mean what could even be done?
mkfs.xfs has had (and mkfs.btrfs now also has) a -f flag that's required to format over an existing volume. That's saved me a few times. However, now that I'm used to it, I bet it won't anymore because I'm already just including -f as second nature. *shrug*
Since "* remove kernel" appears to be inspecific, removing all kernels isn't what I'd expect. It's not how mv or cp or anything else would work.
Ordinary people in the past have done this, and ordinary people in the future will do this. And it will be the same old tech support nightmare of handling it which will lead to eventually someone implementing a "Do you really want to do that" kind of fix. Since I routinely have to help people who do this I expect that it will be enough of an issue for Red Hat eventually to put in the extra logic again as it is expensive to deal with.
Good point. Anything that becomes common and expensive needs a fix when the fix is much cheaper.
Chris Murphy
Dne 6.1.2014 23:26, Chris Murphy napsal(a):
Since "* remove kernel" appears to be inspecific, removing all kernels isn't what I'd expect. It's not how mv or cp or anything else would work.
So why not turn this around. In case somebody is doing "dnf remove kernel" and dnf will figures out that there is more packages, then it should fail and ask user to be more specific. That way dnf could behave consistently and user would have to go with "dnf remove kernel*" to explicitly specify, that (s)he wants to remove all kernels.
Vít
On Tue, 07 Jan 2014 09:48:16 +0100 Vít Ondruch vondruch@redhat.com wrote:
Dne 6.1.2014 23:26, Chris Murphy napsal(a):
Since "* remove kernel" appears to be inspecific, removing all kernels isn't what I'd expect. It's not how mv or cp or anything else would work.
So why not turn this around. In case somebody is doing "dnf remove kernel" and dnf will figures out that there is more packages, then it should fail and ask user to be more specific. That way dnf could behave consistently and user would have to go with "dnf remove kernel*" to explicitly specify, that (s)he wants to remove all kernels.
Vít
dnf remove kernel --all
___ Regards, Frank www.frankly3d.com
On Tue, Jan 7, 2014 at 9:53 AM, Frank Murphy frankly3d@gmail.com wrote:
On Tue, 07 Jan 2014 09:48:16 +0100 Vít Ondruch vondruch@redhat.com wrote:
Dne 6.1.2014 23:26, Chris Murphy napsal(a):
Since "* remove kernel" appears to be inspecific, removing all kernels isn't what I'd expect. It's not how mv or cp or anything else would work.
So why not turn this around. In case somebody is doing "dnf remove kernel" and dnf will figures out that there is more packages, then it should fail and ask user to be more specific. That way dnf could behave consistently and user would have to go with "dnf remove kernel*" to explicitly specify, that (s)he wants to remove all kernels.
Vít
dnf remove kernel --all
I assume you're suggestion that `dnf remove kernel` should only remove the latest kernel.
It wouldn't change the fact that removing only the latest installonly package could most likely remove the running kernel, which is the main issue here.
Regards, Frank www.frankly3d.com
-- 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 Tue, 7 Jan 2014 10:16:16 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
dnf remove kernel --all
I assume you're suggestion that `dnf remove kernel` should only remove the latest kernel.
How do you make that out. Have you ever used "yum remove kernel"
"dnf remove kernel --all" to remove "all"
___ Regards, Frank www.frankly3d.com
On Tue, Jan 7, 2014 at 10:29 AM, Frank Murphy frankly3d@gmail.com wrote:
On Tue, 7 Jan 2014 10:16:16 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
dnf remove kernel --all
I assume you're suggestion that `dnf remove kernel` should only remove the latest kernel.
How do you make that out. Have you ever used "yum remove kernel"
"dnf remove kernel --all" to remove "all"
I'm sorry I don't understand your answer.
Dridi
Regards, Frank www.frankly3d.com
-- 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 Tue, 7 Jan 2014 10:52:52 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
I'm sorry I don't understand your answer.
Dridi
I can't make it any simpler.
___ Regards, Frank www.frankly3d.com
On Tue, Jan 7, 2014 at 11:06 AM, Frank Murphy frankly3d@gmail.com wrote:
On Tue, 7 Jan 2014 10:52:52 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
I'm sorry I don't understand your answer.
Dridi
I can't make it any simpler.
You could maybe explain what you meant in the message I've answered to.
You've just said: dnf remove kernel --all
I'm sorry for misunderstanding a command that didn't come with a single sentence.
Dridi
Regards, Frank www.frankly3d.com
-- 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 Tue, 7 Jan 2014 11:12:39 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
I'm sorry for misunderstanding a command that didn't come with a single sentence.
"dnf remove kernel --all" to remove "all"
What's to misunderstand
___ Regards, Frank www.frankly3d.com
On Tue, Jan 7, 2014 at 11:28 AM, Frank Murphy frankly3d@gmail.com wrote:
On Tue, 7 Jan 2014 11:12:39 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
I'm sorry for misunderstanding a command that didn't come with a single sentence.
"dnf remove kernel --all" to remove "all"
What's to misunderstand
Maybe this time you'll answer my question.
What did you mean here ? https://lists.fedoraproject.org/pipermail/devel/2014-January/193568.html
Regards, Frank www.frankly3d.com
-- 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 Tue, 7 Jan 2014 11:37:23 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
Maybe this time you'll answer my question.
Read Vit's comment and my cli "command" suggestion to it! you may get the answer, instead of looking for meanings' not required
https://lists.fedoraproject.org/pipermail/devel/2014-January/193567.html
___ Regards, Frank www.frankly3d.com
Dne 7.1.2014 10:52, Dridi Boukelmoune napsal(a):
On Tue, Jan 7, 2014 at 10:29 AM, Frank Murphy frankly3d@gmail.com wrote:
On Tue, 7 Jan 2014 10:16:16 +0100 Dridi Boukelmoune dridi.boukelmoune@gmail.com wrote:
dnf remove kernel --all
I assume you're suggestion that `dnf remove kernel` should only remove the latest kernel.
How do you make that out. Have you ever used "yum remove kernel"
"dnf remove kernel --all" to remove "all"
I'm sorry I don't understand your answer.
Dridi
I suggested that to remove all kernels, you should do "dnf remove kernel*" and Frank suggested to replaced the '*' by '--all' option, which is fine or may be even better ;)
Vít
Chris Adams wrote:
The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default).
Not going to happen here, I use the nohostonly and norescue options to disable that nonsense "feature".
So removing all kernels will not only make the system unbootable for the lack of a kernel, but also leave grub.cfg with no kernel listed at all, and thus grubby without a template to write new kernel entries from, ergo I would not only have to reinstall the kernel from a rescue environment, but also manually fix grub.cfg! (Maybe grub2-mkconfig would be sufficient for that purpose these days though. In GRUB 1 days, it meant having to write the entry by hand!)
Kevin Kofler
On 01/05/2014 11:53 PM, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
where would it be useful to uninstall base-package and YUM/DNF itself bringing your system in a non-recoverable state?
I already offered a couple of examples that you ignored (just a couple that came to mind, certainly not an exhaustive list):
When will it be useful and correct to remove the *running* kernel (that is what yum protects you from doing)?
Yum also protects you from removing yum, 'Error: Trying to remove "yum", which is protected'. Is that bad also? As long as you have rpm installed you can download the yum rpm, and re-install yum, so why protects it? Could it be because yum has a user perspective, making it a tad harder for the non technically oriented user to do bad things to the system? Leaving the bad things to the more technically oriented user?
Lars
On Sun, Jan 05, 2014 at 01:06:16PM -0600, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Frankly, that's a dumb "feature" to have the package manager know "magic" things about some names. Why is it dumb? Because some people then depend on magic "features". Is this "feature" even documented anywhere? I don't see it in the yum man page for example.
[...]
This is Unix; system programs are expected to "do what I say". Don't try to code "do what I mean" into it (because what you mean is probably different from what I mean).
We've had kernel variant packages in the past, like kernel-smp and kernel-PAE; are all variants supposed to be handled magically? What if there's a new variant? Would not handling it in the package manager magic be a release-blocker bug?
Kernel packages are special with yum, because multiple packages are installed by default. With your argumentation 'dnf update kernel' should remove the current kernel when a new kernel is installed. Is this really what you expect and what dnf should do? Currently it installs a new kernel without removing the old one as I know it from yum.
Regards Till
Dne 5.1.2014 22:25, Till Maas napsal(a):
On Sun, Jan 05, 2014 at 01:06:16PM -0600, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
Frankly, that's a dumb "feature" to have the package manager know "magic" things about some names. Why is it dumb? Because some people then depend on magic "features". Is this "feature" even documented anywhere? I don't see it in the yum man page for example.
[...]
This is Unix; system programs are expected to "do what I say". Don't try to code "do what I mean" into it (because what you mean is probably different from what I mean).
We've had kernel variant packages in the past, like kernel-smp and kernel-PAE; are all variants supposed to be handled magically? What if there's a new variant? Would not handling it in the package manager magic be a release-blocker bug?
Kernel packages are special with yum, because multiple packages are installed by default. With your argumentation 'dnf update kernel' should remove the current kernel when a new kernel is installed. Is this really what you expect and what dnf should do? Currently it installs a new kernel without removing the old one as I know it from yum.
Regards Till
As far as I know, yum supports installonly packages. While yum supports them, there is still used special hack for kernel. This hack should be removed in first place.
Otherwise, I totally agree with Chris and with DNF upstream. "dnf remove kernel" should remove every kernel and should not behave magically.
Vít
On 01/06/2014 12:43 PM, Vít Ondruch wrote:
Otherwise, I totally agree with Chris and with DNF upstream. "dnf remove kernel" should remove every kernel and should not behave magically.
What would be the point in removing the running kernel? Is there actually such a use case?
Lars
Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a):
On 01/06/2014 12:43 PM, Vít Ondruch wrote:
Otherwise, I totally agree with Chris and with DNF upstream. "dnf remove kernel" should remove every kernel and should not behave magically.
What would be the point in removing the running kernel? Is there actually such a use case?
Lars
Why are you asking? May be you should let your imagination run riot.
I don't even remember I ever needed "yum remove kernel". Does it mean that "yum remove kernel" should not work at all no matter if it leaves running kernel on the system or not? Or should it be completely prohibited? Why we keep 3 versions of kernel on the system anyway?
Also, I'd like to point out that "yum/dnf remove" by default shows what it is going to do and you have to explicitly confirm the action, isn't it enough? How much protection do you need?
Vít
On 01/06/2014 02:06 PM, Vít Ondruch wrote:
Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a):
...
What would be the point in removing the running kernel? Is there actually such a use case?
Lars
Why are you asking? May be you should let your imagination run riot.
Why? Isn't that obvious? If there is no use case for removing the running kernel, well, then there's no reason to let a application do so, isn't it?
Allowing something that has no, or a minuscules use case, while at the same time might create huge problems for non technically oriented user, is, in my opinion, really bad.
Also, I'd like to point out that "yum/dnf remove" by default shows what it is going to do and you have to explicitly confirm the action, isn't it enough? How much protection do you need?
Me? For me personally it dose not matter. The reason I debate this is to help the unsuspecting ordinary non technical users from debunking their systems. The user perspective is good to have sometimes, you know.
Lars
On 01/06/2014 03:32 PM, Lars E. Pettersson wrote:
On 01/06/2014 02:06 PM, Vít Ondruch wrote:
Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a):
...
What would be the point in removing the running kernel? Is there actually such a use case?
Lars
Why are you asking? May be you should let your imagination run riot.
Why? Isn't that obvious? If there is no use case for removing the running kernel, well, then there's no reason to let a application do so, isn't it?
AFAIU, inside a container you don't need a kernel installed.
Allowing something that has no, or a minuscules use case, while at the same time might create huge problems for non technically oriented user, is, in my opinion, really bad.
Also, I'd like to point out that "yum/dnf remove" by default shows what it is going to do and you have to explicitly confirm the action, isn't it enough? How much protection do you need?
Me? For me personally it dose not matter. The reason I debate this is to help the unsuspecting ordinary non technical users from debunking their systems. The user perspective is good to have sometimes, you know.
Lars
This discussion has now reached the "phoronix" point http://www.phoronix.com/scan.php?page=news_item&px=MTU2MTE
Has anyone filed any tickets so we could move forward or will we continue wasting time here ?
Best regards, H.
Am 06.01.2014 15:39, schrieb Petr Viktorin:
On 01/06/2014 03:32 PM, Lars E. Pettersson wrote:
On 01/06/2014 02:06 PM, Vít Ondruch wrote:
Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a):
...
What would be the point in removing the running kernel? Is there actually such a use case?
Lars
Why are you asking? May be you should let your imagination run riot.
Why? Isn't that obvious? If there is no use case for removing the running kernel, well, then there's no reason to let a application do so, isn't it?
AFAIU, inside a container you don't need a kernel installed
so what - i do not need "linux-firmware" on any virtual machine as well as none of the physial ones needs the package - my bugreport remove this useless dependency was rejected
so stop this kind of argumentation
On Mon, Jan 6, 2014 at 3:32 PM, Lars E. Pettersson lars@homer.se wrote:
On 01/06/2014 02:06 PM, Vít Ondruch wrote:
Dne 6.1.2014 13:31, Lars E. Pettersson napsal(a):
...
What would be the point in removing the running kernel? Is there actually such a use case?
Lars
Why are you asking? May be you should let your imagination run riot.
Why? Isn't that obvious? If there is no use case for removing the running kernel, well, then there's no reason to let a application do so, isn't it?
Allowing something that has no, or a minuscules use case, while at the same time might create huge problems for non technically oriented user, is, in my opinion, really bad.
It has been said before, a "non technically oriented user" will probably never hear about yum.
I don't know how GUIs on top of yum behave, but maybe this kind of behavior belongs there. I'm not discarding the possibility of a dnf plugin doing just that, I would probably install and enable it.
To me, yum/dnf adds repository/network capabilities to the vanilla rpm. but yum is also opinionated, because for instance it won't let you install several packages with the same name (even though they don't conflict). Unless of course if you configure them as installonly packages.
Now about yum's do-not-erase-the-running-kernel opinion, it doesn't bother me that much even though I'd rather not include it. But the fact that it is undocumented behavior according to some does bother me. What happens for instance when you use the --installroot flag ?
My 2 cents, Dridi
Also, I'd like to point out that "yum/dnf remove" by default shows what it is going to do and you have to explicitly confirm the action, isn't it enough? How much protection do you need?
Me? For me personally it dose not matter. The reason I debate this is to help the unsuspecting ordinary non technical users from debunking their systems. The user perspective is good to have sometimes, you know.
Lars
Lars E. Pettersson lars@homer.se http://www.sm6rpz.se/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Am 06.01.2014 14:06, schrieb Vít Ondruch:
Also, I'd like to point out that "yum/dnf remove" by default shows what it is going to do and you have to explicitly confirm the action, isn't it enough? How much protection do you need?
to say it clear - *all* protection to avoid breaking the system otherwise as example i would not have learned which packages can be removed resulting in strip down some Fedora servers to 600 MB
what *never* must happen is that YUM or DNF are killing itself, rpm or render the setup unbootable - period - there is *nothing* to discuss
----- Original Message -----
Am 06.01.2014 14:06, schrieb Vít Ondruch:
Also, I'd like to point out that "yum/dnf remove" by default shows what it is going to do and you have to explicitly confirm the action, isn't it enough? How much protection do you need?
to say it clear - *all* protection to avoid breaking the system otherwise as example i would not have learned which packages can be removed resulting in strip down some Fedora servers to 600 MB
what *never* must happen is that YUM or DNF are killing itself, rpm or render the setup unbootable - period - there is *nothing* to discuss
Hm, so the rm should refuse to do "rm /usr/bin/rm", chmod: "chmod -x /usr/bin/chmod", etc., am I getting it right?
Am 06.01.2014 16:12, schrieb Tomas Mlcoch:
Am 06.01.2014 14:06, schrieb Vít Ondruch:
Also, I'd like to point out that "yum/dnf remove" by default shows what it is going to do and you have to explicitly confirm the action, isn't it enough? How much protection do you need?
to say it clear - *all* protection to avoid breaking the system otherwise as example i would not have learned which packages can be removed resulting in strip down some Fedora servers to 600 MB
what *never* must happen is that YUM or DNF are killing itself, rpm or render the setup unbootable - period - there is *nothing* to discuss
Hm, so the rm should refuse to do "rm /usr/bin/rm", chmod: "chmod -x /usr/bin/chmod", etc., am I getting it right?
is "rm" supposed to work this way? is "rm" supposed to be replaced by dnf? is "rm" used to solve dependencies? is "rm" responsible for a consistent package managment?
i guess no because "rm" is not a package-manager someone tries to rewrite
On 6 January 2014 13:06, Vít Ondruch vondruch@redhat.com wrote:
I don't even remember I ever needed "yum remove kernel". Does it mean that "yum remove kernel" should not work at all no matter if it leaves running kernel on the system or not? Or should it be completely prohibited? Why we keep 3 versions of kernel on the system anyway?
Is that last a real question?
Dne 7.1.2014 11:34, Ian Malone napsal(a):
On 6 January 2014 13:06, Vít Ondruch vondruch@redhat.com wrote:
I don't even remember I ever needed "yum remove kernel". Does it mean that "yum remove kernel" should not work at all no matter if it leaves running kernel on the system or not? Or should it be completely prohibited? Why we keep 3 versions of kernel on the system anyway?
Is that last a real question?
More or less, but:
* it is OT for this thread * I don't think discussion about this topic would bring anything new
So you can safely ignore it ;)
Vít
Am 07.01.2014 12:06, schrieb Vít Ondruch:
Dne 7.1.2014 11:34, Ian Malone napsal(a):
On 6 January 2014 13:06, Vít Ondruch vondruch@redhat.com wrote:
I don't even remember I ever needed "yum remove kernel". Does it mean that "yum remove kernel" should not work at all no matter if it leaves running kernel on the system or not? Or should it be completely prohibited? Why we keep 3 versions of kernel on the system anyway?
Is that last a real question?
More or less, but:
- it is OT for this thread
- I don't think discussion about this topic would bring anything new
So you can safely ignore it ;)
off-topic or not why?
because it happens from time to time that a new kernel refuses to boot depending on the hardware and setup and from FC3 until now it did not happen a single time that you could not move the cursor down in the boot-menu, boot with the old installed kernel and write a bugreport
without this option you can be sure that you lose most early kernel testsers like me from one second to the next
is that answer enough?
On 01/05/2014 07:07 PM, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote:
...
The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?),
They didn't. Both work on both.
It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs.
As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one.
dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too.
As a side not 'dnf --help' shows:
'--version show Yum version and exit'
which probably also is wrong.
This is by no mean any excoriation of the dnf devs on my part.
Three documentation "bugs" out of a side track of a thread is not a terrible thread, in my opinion...
Lars
On 01/05/2014 07:24 PM, Lars E. Pettersson wrote:
As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one.
Pressed send a bit too early. Should of course be 'erase' here, not 'remove'... :)
Lars
A solution may be for someone to write a plugin that restores the protected packages feature.
Fedora users are clearly used to such a feature and expect it while upstream doesnt want to add hand holding features, but provide a method to do the same.
On 5 January 2014 18:32, Lars E. Pettersson lars@homer.se wrote:
On 01/05/2014 07:24 PM, Lars E. Pettersson wrote:
As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one.
Pressed send a bit too early. Should of course be 'erase' here, not 'remove'... :)
Lars
Lars E. Pettersson lars@homer.se http://www.sm6rpz.se/ -- 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 2014-01-05 19:24, Lars E. Pettersson wrote:
On 01/05/2014 07:07 PM, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote:
...
The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?),
They didn't. Both work on both.
It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs.
As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one.
dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too.
As a side not 'dnf --help' shows:
'--version show Yum version and exit'
which probably also is wrong.
This is by no mean any excoriation of the dnf devs on my part.
Three documentation "bugs" out of a side track of a thread is not a terrible thread, in my opinion...
Lars
Add one doc bug for yum-builddep whtch I filed while messing around after reading this - that makes four.
--alec
On Sun, 2014-01-05 at 19:24 +0100, Lars E. Pettersson wrote:
On 01/05/2014 07:07 PM, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:04 -0800, Adam Williamson wrote:
On Sun, 2014-01-05 at 10:27 +0100, Lars E. Pettersson wrote:
...
The running kernel should not be removed with a simple 'dnf erase kernel' (why did they change remove into erase?),
They didn't. Both work on both.
It's symptomatic of how fucking terrible this thread is, btw, that people would post without checking any of this. It takes about ten seconds to open a kernel and run 'yum remove foo', 'yum erase foo', 'dnf remove foo', 'dnf erase foo'. If you're not going to go to *that* much trouble, it's a bit rich to start excoriating the dnf devs.
As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one.
dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too.
As a side not 'dnf --help' shows:
'--version show Yum version and exit'
which probably also is wrong.
This is by no mean any excoriation of the dnf devs on my part.
Three documentation "bugs" out of a side track of a thread is not a terrible thread, in my opinion...
If it exists for backward compatibility, it doesn't necessarily need to be documented.
On 01/06/2014 12:46 AM, Adam Williamson wrote:
On Sun, 2014-01-05 at 19:24 +0100, Lars E. Pettersson wrote:
...
As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one.
dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too.
As a side not 'dnf --help' shows:
'--version show Yum version and exit'
which probably also is wrong.
This is by no mean any excoriation of the dnf devs on my part.
Three documentation "bugs" out of a side track of a thread is not a terrible thread, in my opinion...
If it exists for backward compatibility, it doesn't necessarily need to be documented.
Ehh? Why? Could you elaborate?
Lars
On Mon, 2014-01-06 at 08:01 +0100, Lars E. Pettersson wrote:
On 01/06/2014 12:46 AM, Adam Williamson wrote:
On Sun, 2014-01-05 at 19:24 +0100, Lars E. Pettersson wrote:
...
As I mentioned before I only auto completed yum, remove is not party of the auto completed commands. If remove should be there, then this is a bug. I will file one.
dnf has no auto completion and I have only seen reference to erase. The man page of dnf does not mention remove (it mentions 'group remove'). This should probably be added. I will file a bug on that one too.
As a side not 'dnf --help' shows:
'--version show Yum version and exit'
which probably also is wrong.
This is by no mean any excoriation of the dnf devs on my part.
Three documentation "bugs" out of a side track of a thread is not a terrible thread, in my opinion...
If it exists for backward compatibility, it doesn't necessarily need to be documented.
Ehh? Why? Could you elaborate?
I don't see what needs elaborating. I'm not aware that the 11th commandment is "Every Subcommand Must Be Documented, Even Ones You Just Put In So People Still Using Syntax From The Old Tool You're Replacing Won't Have A Problem". If that's the only reason a synonym of a documented subcommand exists, what's the point of documenting it? Anyone who needs it doesn't need documentation to find it - that's the *point*, if they were going to read the documentation, they'd know the *new* subcommand - and anyone who reads the documentation doesn't stand to gain anything from learning that a subcommand has a synonym for backwards compatibility purposes. So, why go to the trouble?
On Sun, 2014-01-05 at 23:13 -0800, Adam Williamson wrote:
I don't see what needs elaborating. I'm not aware that the 11th commandment is "Every Subcommand Must Be Documented, Even Ones You Just Put In So People Still Using Syntax From The Old Tool You're Replacing Won't Have A Problem". If that's the only reason a synonym of a documented subcommand exists, what's the point of documenting it? Anyone who needs it doesn't need documentation to find it - that's the *point*, if they were going to read the documentation, they'd know the *new* subcommand - and anyone who reads the documentation doesn't stand to gain anything from learning that a subcommand has a synonym for backwards compatibility purposes. So, why go to the trouble?
One thing I find a bit inconsistent, though, is that the manpage documents "dnf erase", but "dnf group remove". :) Picking one verb or the other and sticking with it seems advised.
On 01/06/2014 08:13 AM, Adam Williamson wrote:
On Mon, 2014-01-06 at 08:01 +0100, Lars E. Pettersson wrote:
On 01/06/2014 12:46 AM, Adam Williamson wrote:
...
If it exists for backward compatibility, it doesn't necessarily need to be documented.
Ehh? Why? Could you elaborate?
I don't see what needs elaborating. I'm not aware that the 11th commandment is "Every Subcommand Must Be Documented, Even Ones You Just Put In So People Still Using Syntax From The Old Tool You're Replacing Won't Have A Problem". If that's the only reason a synonym of a documented subcommand exists, what's the point of documenting it? Anyone who needs it doesn't need documentation to find it - that's the *point*, if they were going to read the documentation, they'd know the *new* subcommand - and anyone who reads the documentation doesn't stand to gain anything from learning that a subcommand has a synonym for backwards compatibility purposes. So, why go to the trouble?
The reason for me asking was that you accused me of "excoriating the dnf devs" (a rather harsh accusation) just because I did not try erase/remove. I looked at the documentation and used auto completion. Why would I try a number of different sub-commands if they were not documented?
If a thing is not documented, it does not exist. The first rule of documenting. If it exist, but is mot documented, there's a fault in the documentation. Even if the sub-commands are there for backward compatibility, they need to be documented for people to find them.
Lars
On Mon, 2014-01-06 at 09:26 +0100, Lars E. Pettersson wrote:
On 01/06/2014 08:13 AM, Adam Williamson wrote:
On Mon, 2014-01-06 at 08:01 +0100, Lars E. Pettersson wrote:
On 01/06/2014 12:46 AM, Adam Williamson wrote:
...
If it exists for backward compatibility, it doesn't necessarily need to be documented.
Ehh? Why? Could you elaborate?
I don't see what needs elaborating. I'm not aware that the 11th commandment is "Every Subcommand Must Be Documented, Even Ones You Just Put In So People Still Using Syntax From The Old Tool You're Replacing Won't Have A Problem". If that's the only reason a synonym of a documented subcommand exists, what's the point of documenting it? Anyone who needs it doesn't need documentation to find it - that's the *point*, if they were going to read the documentation, they'd know the *new* subcommand - and anyone who reads the documentation doesn't stand to gain anything from learning that a subcommand has a synonym for backwards compatibility purposes. So, why go to the trouble?
The reason for me asking was that you accused me of "excoriating the dnf devs" (a rather harsh accusation) just because I did not try erase/remove. I looked at the documentation and used auto completion. Why would I try a number of different sub-commands if they were not documented?
Because you're suggesting that they no longer exist? Making sure the thing you claim no longer exists *actually no longer exists* seems like a pre-requisite of making such a claim.
If a thing is not documented, it does not exist.
No, I think you're confused. If it's not documented, it's not documented. If it doesn't exist, it doesn't exist. Two different conditions, see. One related to existence. One to documentation. ;)
The first rule of documenting. If it exist, but is mot documented, there's a fault in the documentation. Even if the sub-commands are there for backward compatibility, they need to be documented for people to find them.
Um. No. No they don't. I've been running 'dnf remove' for weeks.
On 01/06/2014 05:04 PM, Adam Williamson wrote: ...
The reason for me asking was that you accused me of "excoriating the dnf devs" (a rather harsh accusation) just because I did not try erase/remove. I looked at the documentation and used auto completion. Why would I try a number of different sub-commands if they were not documented?
Because you're suggesting that they no longer exist? Making sure the thing you claim no longer exists *actually no longer exists* seems like a pre-requisite of making such a claim.
Well, they are not documented. That should be enough to test. (I have added these documentation bugs to Bugzilla, and next version of dnf will now show both uses, hopefully the yum bug will be corrected soon also)
If a thing is not documented, it does not exist.
No, I think you're confused. If it's not documented, it's not documented. If it doesn't exist, it doesn't exist. Two different conditions, see. One related to existence. One to documentation. ;)
Your quote was one sentence too little. The second sentence was "The first rule of documenting". I.e. the first rule of documenting is that something that is not documented does not exist. I.e. make sure that your documentation fully document what the application (in this case) is capable of doing, including all sub commands, options, etc.
The reasoning behind this is so that a user can get the full picture of the application by only reading the documentation. He/she should not need to try things, they should be documented, if they are not documented, then it is a documentation bug.
Lars
On Mon, 2014-01-06 at 17:22 +0100, Lars E. Pettersson wrote:
On 01/06/2014 05:04 PM, Adam Williamson wrote: ...
The reason for me asking was that you accused me of "excoriating the dnf devs" (a rather harsh accusation) just because I did not try erase/remove. I looked at the documentation and used auto completion. Why would I try a number of different sub-commands if they were not documented?
Because you're suggesting that they no longer exist? Making sure the thing you claim no longer exists *actually no longer exists* seems like a pre-requisite of making such a claim.
Well, they are not documented. That should be enough to test. (I have added these documentation bugs to Bugzilla, and next version of dnf will now show both uses, hopefully the yum bug will be corrected soon also)
If a thing is not documented, it does not exist.
No, I think you're confused. If it's not documented, it's not documented. If it doesn't exist, it doesn't exist. Two different conditions, see. One related to existence. One to documentation. ;)
Your quote was one sentence too little. The second sentence was "The first rule of documenting". I.e. the first rule of documenting is that something that is not documented does not exist. I.e. make sure that your documentation fully document what the application (in this case) is capable of doing, including all sub commands, options, etc.
The reasoning behind this is so that a user can get the full picture of the application by only reading the documentation. He/she should not need to try things, they should be documented, if they are not documented, then it is a documentation bug.
I understand the argument you were trying to make, but I think it's putting things far too strongly, so I provided a flippant reply as an indication of this belief.
The xkcd link I posted in another context I think sufficiently indicates that things that aren't documented certainly *do* exist...=)
It's a nice theory. Sure. It's not a tenable basis on which to operate in the real world of software. So if you want to argue that something doesn't exist, check whether it exists. If you only check the documentation, you're not checking the software, whatever your philosophy on documentation (and there are others besides yours).
On 01/06/2014 05:42 PM, Adam Williamson wrote:
It's a nice theory. Sure. It's not a tenable basis on which to operate in the real world of software. So if you want to argue that something doesn't exist, check whether it exists. If you only check the documentation, you're not checking the software, whatever your philosophy on documentation (and there are others besides yours).
Well, undocumented 'features' always create problems, see this thread and protected packages in yum. As they are undocumented people argue about them etc. Include them i the documentation, and everyone knows about it.
Regarding 'real world'. Correct, that's why I wrote "...if they are not documented, then it is a documentation bug.", and that's how it should be treated.
Lars
On Mon, Jan 6, 2014 at 8:13 AM, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2014-01-06 at 08:01 +0100, Lars E. Pettersson wrote:
On 01/06/2014 12:46 AM, Adam Williamson wrote:
If it exists for backward compatibility, it doesn't necessarily need to be documented.
Ehh? Why? Could you elaborate?
I don't see what needs elaborating. I'm not aware that the 11th commandment is "Every Subcommand Must Be Documented, Even Ones You Just Put In So People Still Using Syntax From The Old Tool You're Replacing Won't Have A Problem". If that's the only reason a synonym of a documented subcommand exists, what's the point of documenting it? Anyone who needs it doesn't need documentation to find it - that's the *point*, if they were going to read the documentation, they'd know the *new* subcommand - and anyone who reads the documentation doesn't stand to gain anything from learning that a subcommand has a synonym for backwards compatibility purposes. So, why go to the trouble?
To make sure the inevitable next generation of contributors (or authors of a rewrite) know not to throw the feature away, or design a new system in a way that makes the feature impossible. It doesn't necessarily need to be very emphasized, but it should be appropriately documented. Mirek
On 01/05/2014 07:24 PM, Lars E. Pettersson wrote:
Three documentation "bugs" out of a side track of a thread is not a terrible thread, in my opinion...
Yum auto completion missing erase: https://bugzilla.redhat.com/show_bug.cgi?id=1048714
dnf man page missing to mention remove: https://bugzilla.redhat.com/show_bug.cgi?id=1048716
In 'dnf --help' option '--version' uses package name Yum instead of dnf: https://bugzilla.redhat.com/show_bug.cgi?id=1048719
Lars
On 04/01/14 11:56 AM, Rahul Sundaram wrote:
Hi
- autoremove (plugin) (https://bugzilla.redhat.com/show_bug.cgi?id=963345)
I closed this report because the current release of yum includes documentation of autoremove.
Regards,
Luya
On Sat, 4 Jan 2014 14:56:04 -0500 Rahul Sundaram metherid@gmail.com wrote:
- yum remove kernel vs dnf remove kernel difference (unfiled? )
https://bugzilla.redhat.com/show_bug.cgi?id=1049310
___ Regards, Frank www.frankly3d.com
On Thu, 02 Jan 2014 14:36:08 -0500 Steve Clark sclark@netwolves.com wrote:
If is a drop in replacement for yum - then why not call it yum, then there is "no" learning curve.
It's not a d.i.r.: https://lists.fedoraproject.org/pipermail/devel/2014-January/193312.html
___ Regards, Frank www.frankly3d.com
On Thu, Jan 2, 2014 at 11:25 AM, Dan Mashal dan.mashal@gmail.com wrote:
On Thu, Jan 2, 2014 at 11:09 AM, Richard Vickery richard.vickeryrv@gmail.com wrote:
On Thu, Jan 2, 2014 at 7:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html
https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
and yes "yum remove kernel" is a *minimum* to handeled properly
there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines guess how abused they are if they have completly different behavior because dveleopers tend to call anything they don't like to implement a "border case"
Reindl makes a very good case here against the adoption. The last thing
we
want is to cause confusion in the community. It may be very wise to wait
and
give the community more time to absorb dnf. I confess that it would be a learning curve for me to use this command: I could imagine the headaches
it
would bring others with much more pressing deadlines.
my 2 cents,
I don't understand what the learning curve is? It works exactly the same as yum. Typing 'dnf' instead of 'yum' is a learning curve?
I'm confused.
Dan
meaning "how does the end user deploy - or use - dnf?"
Am 02.01.2014 20:25, schrieb Dan Mashal:
On Thu, Jan 2, 2014 at 11:09 AM, Richard Vickery richard.vickeryrv@gmail.com wrote:
On Thu, Jan 2, 2014 at 7:28 AM, Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
and yes "yum remove kernel" is a *minimum* to handeled properly
there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines guess how abused they are if they have completly different behavior because dveleopers tend to call anything they don't like to implement a "border case"
Reindl makes a very good case here against the adoption. The last thing we want is to cause confusion in the community. It may be very wise to wait and give the community more time to absorb dnf. I confess that it would be a learning curve for me to use this command: I could imagine the headaches it would bring others with much more pressing deadlines.
I don't understand what the learning curve is? It works exactly the same as yum. Typing 'dnf' instead of 'yum' is a learning curve?
I'm confused
Richard Hughes: It's not a drop-in replacement
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
the bahvior is obviously not (or *not yet*) identical and the viewpoint what are not often used bordercases may vary and depend on the environment as i pointed out "yum -y remove kernel" is a regular task here after machines are running long enough with the last recent one as cleanup
and because that and beause there are voices saying DNF will probably replace YUM with Fedora 22 are the reason i started this thread to make aware that this may be a critical change
someone may say: Fedora 22 is far away - not entirely true because F21 will be released most likely this summer and if the 6 months release cycle holds F22 end 2014 or at least at the begin of 2015
so the only thing i wanted to point out is: please be careful with decisions expierience shows if decisions happened they are not reverted, so it needs take care *before* and if DNF replaces YUM later (F23, F24, F25) it could be a valid option to rename it back to YUM and make a real drop-in replace without any harm
Hi
On Thu, Jan 2, 2014 at 3:14 PM, Reindl Harald wrote:
the bahvior is obviously not (or *not yet*) identical and the viewpoint what are not often used bordercases may vary and depend on the environment as i pointed out "yum -y remove kernel" is a regular task here after machines are running long enough with the last recent one as cleanup
I agree with that and the kernel removal behavior isn't the only difference. I mean, how often would one run dnf remove glibc on purpose and the significant amount of accidental runs of yum that caused serious problems resulted in yum developers adding some protection against removing key packages. dnf changing this expected behavior is problem and clearly this is a design decision which I think needs to revisited.
http://akozumpl.github.io/dnf/cli_vs_yum.html#protected-packages-is-ignored
Rahul
Am 02.01.2014 21:21, schrieb Rahul Sundaram:
On Thu, Jan 2, 2014 at 3:14 PM, Reindl Haraldwrote: the bahvior is obviously not (or *not yet*) identical and the viewpoint what are not often used bordercases may vary and depend on the environment as i pointed out "yum -y remove kernel" is a regular task here after machines are running long enough with the last recent one as cleanup
I agree with that and the kernel removal behavior isn't the only difference. I mean, how often would one run dnf remove glibc on purpose and the significant amount of accidental runs of yum that caused serious problems resulted in yum developers adding some protection against removing key packages. dnf changing this expected behavior is problem and clearly this is a design decision which I think needs to revisited.
http://akozumpl.github.io/dnf/cli_vs_yum.html#protected-packages-is-ignored
thank you!
that and the plugins / utilities below should be taken care of and than IMHO DNF will be a *painless* drop-in replacement, working that way and after it has that state it could be really replace yum including respect the existing configuration of /etc/yum.conf and /etc/yum.repos.d/ with excludes, includes
yum-utils yum-plugin-security yum-plugin-tsflags yum-plugin-protectbase yum-presto
one example of a production machine which pulls it's updates from cache-repos only so no deltarpm and no manuals on all servers needed, that's why the cache-repo is filled with the script below for several resons
* only one machine producing traffic on the mirrors * 100% identical packages while otherwise one may hit a newer mirror * the buildserver has for most packages sample-configs and autotests * so while reduce WAN-traffic dramatically there are only tested packages inside the whole network
that's some of the "small" things one needs to take care in production and only the renaming of /var/cache/yum to /var/cache/dnf may produce side-effects even with otherwise identical behavior _______________________________________________
[main] cachedir=/var/cache/yum installonly_limit=2 metadata_expire=60m clean_requirements_on_remove=1 tsflags=nodocs deltarpm=0
[root@buildserver:~]$ cat /buildserver/repo-cache.sh #!/usr/bin/bash basearch=`uname -i` releasever=`rpm -q --qf "%{version}\n" fedora-release` for g in `ls -1b /var/cache/yum` do if [ -d /var/cache/yum/$g/packages ] then echo "/var/cache/yum/$g/packages/ > /repo/cache/fc$releasever/" sudo mv --verbose /var/cache/yum/$g/packages/*.rpm /repo/cache/fc$releasever/ 2> /dev/null fi done /buildserver/repo-create.sh
On Thu, Jan 02, 2014 at 03:21:37PM -0500, Rahul Sundaram wrote:
I agree with that and the kernel removal behavior isn't the only difference. I mean, how often would one run dnf remove glibc on purpose and the significant amount of accidental runs of yum that caused serious problems resulted in yum developers adding some protection against removing key packages. dnf changing this expected behavior is problem and clearly this is a design decision which I think needs to revisited. http://akozumpl.github.io/dnf/cli_vs_yum.html#protected-packages-is-ignored
This one is clearly one of those "doomed to repeat history" things in motion.
Protected packages was first implemented * as a yum plugin because Seth thought it was kind of crazy and shouldn't be core functionality, but then it proved itself in real use and became built-in. Now, the DNF pages says "Similar functionality can be implemented by a plugin", putting us right back where we were. **
* originally as a feature for BU Linux :) ** well, except that I don't have an intern interested in writing the plugin this time around. Volunteers welcome!
Hi
On Thu, Jan 2, 2014 at 3:52 PM, Matthew Miller wrote:
This one is clearly one of those "doomed to repeat history" things in motion.
Protected packages was first implemented * as a yum plugin because Seth thought it was kind of crazy and shouldn't be core functionality, but then it proved itself in real use and became built-in. Now, the DNF pages says "Similar functionality can be implemented by a plugin", putting us right back where we were. **
Pretty much, yeah. I remember trying to convince Seth to merge the functionality and got pretty similar replies to what I hear from Ales now. Similar issues at https://bugzilla.redhat.com/show_bug.cgi?id=1044984 and https://bugzilla.redhat.com/show_bug.cgi?id=1044984. I really dislike going through the same process twice. Pushing such functionality out into plugins won't work well either because by the time users realize that such a plugin exists and they might need them, it is likely to be too late and if you discard existing features without understanding the use cases fully, you will end up creating a rough transition for users. If someone is going to replace A with B, it would be nice for the developers involved to go through the release history and bugs and find out why the current functionality was done the way it was before deciding to change it.
Rahul
Le jeudi 02 janvier 2014 à 16:08 -0500, Rahul Sundaram a écrit :
Hi
On Thu, Jan 2, 2014 at 3:52 PM, Matthew Miller wrote: This one is clearly one of those "doomed to repeat history" things in motion.
Protected packages was first implemented * as a yum plugin because Seth thought it was kind of crazy and shouldn't be core functionality, but then it proved itself in real use and became built-in. Now, the DNF pages says "Similar functionality can be implemented by a plugin", putting us right back where we were. **Pretty much, yeah. I remember trying to convince Seth to merge the functionality and got pretty similar replies to what I hear from Ales now. Similar issues at https://bugzilla.redhat.com/show_bug.cgi?id=1044984 and https://bugzilla.redhat.com/show_bug.cgi?id=1044984. I really dislike going through the same process twice. Pushing such functionality out into plugins won't work well either because by the time users realize that such a plugin exists and they might need them, it is likely to be too late and if you discard existing features without understanding the use cases fully, you will end up creating a rough transition for users. If someone is going to replace A with B, it would be nice for the developers involved to go through the release history and bugs and find out why the current functionality was done the way it was before deciding to change it.
It could be implemented as a plugin and still installed by default.
Hi
On Thu, Jan 2, 2014 at 4:36 PM, Michael Scherer wrote:
It could be implemented as a plugin and still installed by default.
It could be but I doubt that is the proposed change here. They just don't want to deal with the functionality at all and seem to have some sort of philosophical argument against it being the default behavior. The argument from the other side apparently is that users asked for it and they should get exactly what they asked even if doesn't make any sense mostly and the program they intend to replace it with has been used already with this functionality for several years which is bound to trip up users during the proposed transition. Also I don't see the advantage of that over just merging the functionality and adding a configuration option.
Rahul
Le jeudi 02 janvier 2014 à 16:45 -0500, Rahul Sundaram a écrit :
Hi
On Thu, Jan 2, 2014 at 4:36 PM, Michael Scherer wrote: It could be implemented as a plugin and still installed by default.
It could be but I doubt that is the proposed change here. They just don't want to deal with the functionality at all and seem to have some sort of philosophical argument against it being the default behavior. The argument from the other side apparently is that users asked for it and they should get exactly what they asked even if doesn't make any sense mostly and the program they intend to replace it with has been used already with this functionality for several years which is bound to trip up users during the proposed transition.
With people complaining all over the place that we do not respect anymore the unix way, here is a case where we let people shoot them in the foot.
Also I don't see the advantage of that over just merging the functionality and adding a configuration option.
I could see a few. having a plugin permit to have it more extensible. For example, let's say I want to have a system that act a bit smarter, and prevent removing kernel, and several others stuff depending on the hostname ( ie, in a classroom where people are using VM to test ). Or imagine I want to let kernel be removed because the system is in a container, so I can detect the container type and decide to let people remove or not.
If all is set in stone in the main software, then we can hardly permit theses use cases.
And for the record, i would be in favor of having a safeguard by default. In fact having it in a plugin permit to anybody to have it enabled or not in a downstream consumer, and this could even be a per-WG change.
Hi
On Fri, Jan 3, 2014 at 7:01 AM, Michael Scherer wrote:
I could see a few. having a plugin permit to have it more extensible. For example, let's say I want to have a system that act a bit smarter, and prevent removing kernel, and several others stuff depending on the hostname ( ie, in a classroom where people are using VM to test ). Or imagine I want to let kernel be removed because the system is in a container, so I can detect the container type and decide to let people remove or not.
If all is set in stone in the main software, then we can hardly permit theses use cases.
It is not quite either/or though. I would say, providing some safety as part of the core and have plugins extend the base model with extra features is the right approach here as opposed to delegating it entirely to a plugin and have that plugin installed by default. In any case, if dnf developers were not opposed to having this level of safety from being there by default, it wouldn't be really an issue regardless of whether the feature is implementing via a plugin or not which is an implementation detail most users wouldn't be concerned about.
Rahul
On Thu, Jan 2, 2014 at 3:52 PM, Matthew Miller mattdm@fedoraproject.org wrote:
This one is clearly one of those "doomed to repeat history" things in motion.
It seems to me that dbf has to strike an impossible balance.
Asking that dnf supports every yum behavior would negate the benefit of having dnf, which is to break from the heavy corset of backwards compat yum wears.
So the dev team has to pick and choose. Not an easy spot to be in. Perhaps some civility would help. Remember: every feature has a vocal fan, but if they appease you and all the others, we're back to where we started -- yum.
m
Am 02.01.2014 23:09, schrieb Martin Langhoff:
On Thu, Jan 2, 2014 at 3:52 PM, Matthew Miller mattdm@fedoraproject.org wrote:
This one is clearly one of those "doomed to repeat history" things in motion.
It seems to me that dbf has to strike an impossible balance.
not necessarily
Asking that dnf supports every yum behavior would negate the benefit of having dnf, which is to break from the heavy corset of backwards compat yum wears.
with my software-developer hat on the opposite is true
* many features are grown in a organic way * many of the codebase was not designed for them * a rewrite with a new codebase has or should have a different, optimized internal architecture * with starting the rewrite you have the one-time chance avoid many of the organic growing
So the dev team has to pick and choose. Not an easy spot to be in. Perhaps some civility would help. Remember: every feature has a vocal fan, but if they appease you and all the others, we're back to where we started -- yum
no, clearly no
the target of a rewrite should be support all the over years grown features but avoid the design mistakes that made some of them a bad hack in the past
starting with cut off features and later add them with hacks clearly brings you back from where you came
that is why a rewrite starting by throwing all away instead look what you have and need to support instead adjust your software-design from the first line by knowing all these things by learning from the past is the wrong start and will end in circles where are you after some time at the same point you started from
in case of a really good software-design you drop in and out core and plugins without taking notice from the enduser view because all parts are working with API's - that should be the goal of a rewrite
On Thu, Jan 2, 2014 at 5:21 PM, Reindl Harald h.reindl@thelounge.net wrote:
with my software-developer hat on the opposite is true
I discussed yum internals quite a bit with Seth in past years. Every change I proposed met a wall of backwards compatibility. Turns out that there are many very specific corner cases, and yum has it on its shoulders to not mess with them.
AIUI, the yum team has refactored quite a bit in place, and that's what you seem to be referring to.
dnf is a chance to drop some of that backwards compat and move forward. Users (usually corporate) that have a rigid need of the old behavior can continue to use yum for as it is maintained; and it is likely that RH would keep it maintained for a long time.
I expect yum to continue to live as the backwards compat tool, even as dnf takes center stage.
Please respect that others may have knowledge and experience that you don't, you are coming across as rather argumentative.
cheers,
m
Am 02.01.2014 23:29, schrieb Martin Langhoff:
On Thu, Jan 2, 2014 at 5:21 PM, Reindl Harald h.reindl@thelounge.net wrote:
with my software-developer hat on the opposite is true
I discussed yum internals quite a bit with Seth in past years. Every change I proposed met a wall of backwards compatibility. Turns out that there are many very specific corner cases, and yum has it on its shoulders to not mess with them.
that's the difference of a change between a complete rewrite having the supported end-product with it'fs features in mind
AIUI, the yum team has refactored quite a bit in place, and that's what you seem to be referring to.
i did not speak about refactoring
i spoke about a complete rewrite as it happens but with not start with a limited feature set to make things easier at the start and finally end at the same problems some years later
dnf is a chance to drop some of that backwards compat and move forward
and where does throw away existing code while start from scratch means that you need to throw away features and bahvior too instead only get rid of the old codebase?
Users (usually corporate) that have a rigid need of the old behavior can continue to use yum for as it is maintained; and it is likely that RH would keep it maintained for a long time.
which does say nothing about Fedora
I expect yum to continue to live as the backwards compat tool, even as dnf takes center stage.
maybe, maybe not sysvinit was also in the F15 repos and not use/installable
Please respect that others may have knowledge and experience that you don't, you are coming across as rather argumentative
please respect that you know not much about my knowledge
i maintain a large-codebase which started long before Fedora existed for some hundret instances and did rewrites of many components over the last 10 years without taking the enduser notice
it takes more time, but the result have few to no compromises and at no point in time any existing user was disappointed
On Thu, Jan 02, 2014 at 03:52:00PM -0500, Matthew Miller wrote:
Protected packages was first implemented * as a yum plugin because Seth thought it was kind of crazy and shouldn't be core functionality, but then it proved itself in real use and became built-in. Now, the DNF pages says "Similar functionality can be implemented by a plugin", putting us right back where we were. **
Putting such functionality in a plugin is actually a bad idea, because those plugins only work for dnf. But packagekit does not use dnf, instead it directly calls functions from the hawkey library.
Cheers, Michael.
can we *please* agree that discussions @devel are *technical* without noise (smalltalk and joke-posts)
Am 02.01.2014 21:18, schrieb poma:
On 02.01.2014 20:25, Dan Mashal wrote:
I don't understand what the learning curve is? It works exactly the same as yum. Typing 'dnf' instead of 'yum' is a learning curve?
Really?
I'm confused.
Of course. You write as if you never even tried it. :)
Am 02.01.2014 21:15, schrieb poma:> On 02.01.2014 20:36, Steve Clark wrote:
Also at least yum stood for something - Yellowdog Updater, Modified - as opposed to being some nonsensical conglomeration of letters. The only thing I am aware of that dnf means is "did not finish".
Did Not Finish Do Not Forget Does Not Follow Data Not Found Did Not Find Does Not Function Do Not Freeze Do Not Fix Do Not Fax Do Not Forward
Hi,
To me, this is the real showstopper: http://akozumpl.github.io/dnf/cli_vs_yum.html#keepcache-configuration-option... (By the way, how does PackageKit-hawkey behave there?)
The keepcache=0 default in Fedora is IMHO a CRITICAL DATA LOSS BUG and I ALWAYS change that broken default to 1 on my machines. This ensures that if an update is broken, I can always revert to the previous update that I still have cached, not only to the ancient version from GA that might not even install anymore, and that also has many bugs and security issues! Especially considering that Fedora does not keep previous updates on its mirrors, it is TOTALLY IRRESPONSIBLE to delete the cache by default, and EVEN MORE UNACCEPTABLE to remove the keepcache option entirely!
I actually don't understand why anyone would actually want to have keepcache=0!
I also think that: http://akozumpl.github.io/dnf/cli_vs_yum.html#clean-requirements-on-remove-o... is a very bad idea (the depsolver shouldn't be removing things that I neither asked to be removed nor strictly have to be removed for dependency reasons when removing the things I actually asked to be removed), but at least that option is still there.
Kevin Kofler
Am 03.01.2014 03:05, schrieb Kevin Kofler:
To me, this is the real showstopper: http://akozumpl.github.io/dnf/cli_vs_yum.html#keepcache-configuration-option... (By the way, how does PackageKit-hawkey behave there?)
The keepcache=0 default in Fedora is IMHO a CRITICAL DATA LOSS BUG and I ALWAYS change that broken default to 1 on my machines. This ensures that if an update is broken, I can always revert to the previous update that I still have cached, not only to the ancient version from GA that might not even install anymore, and that also has many bugs and security issues! Especially considering that Fedora does not keep previous updates on its mirrors, it is TOTALLY IRRESPONSIBLE to delete the cache by default, and EVEN MORE UNACCEPTABLE to remove the keepcache option entirely!
ok, until this is fixed DNF is a complete no-go
* there is no need to completly mirror the fedora repos because on our buildserver are exactly 1170 installed and they cover any setup over a lot of machines, after a dist-upgrade within a minute the cache is filled * it's unacepptable to download updates (regulary and dist-upgrades) on each machine in a production environment because unpredictable results in case of different mirrors as well as you can't update test-servers and after all is fine two days later their production-buddy * it is a useless burden for the mirror traffic
this script below works since many years and anybody who thinks /var/cache/yum/ is not important never had to maintain 10, 20, 30 or more Fedora machines
root@buildserver:~]$ cat /buildserver/repo-cache.sh #!/usr/bin/bash basearch=`uname -i` releasever=`rpm -q --qf "%{version}\n" fedora-release` for g in `ls -1b /var/cache/yum` do if [ -d /var/cache/yum/$g/packages ] then echo "/var/cache/yum/$g/packages/ > /repo/cache/fc$releasever/" sudo mv --verbose /var/cache/yum/$g/packages/*.rpm /repo/cache/fc$releasever/ 2> /dev/null fi done /buildserver/repo-create.sh
Am 03.01.2014 03:12, schrieb Reindl Harald:
Am 03.01.2014 03:05, schrieb Kevin Kofler:
To me, this is the real showstopper: http://akozumpl.github.io/dnf/cli_vs_yum.html#keepcache-configuration-option... (By the way, how does PackageKit-hawkey behave there?)
The keepcache=0 default in Fedora is IMHO a CRITICAL DATA LOSS BUG and I ALWAYS change that broken default to 1 on my machines. This ensures that if an update is broken, I can always revert to the previous update that I still have cached, not only to the ancient version from GA that might not even install anymore, and that also has many bugs and security issues! Especially considering that Fedora does not keep previous updates on its mirrors, it is TOTALLY IRRESPONSIBLE to delete the cache by default, and EVEN MORE UNACCEPTABLE to remove the keepcache option entirely!
ok, until this is fixed DNF is a complete no-go
- there is no need to completly mirror the fedora repos because on our buildserver are exactly 1170 installed and they cover any setup over a lot of machines, after a dist-upgrade within a minute the cache is filled
- it's unacepptable to download updates (regulary and dist-upgrades) on each machine in a production environment because unpredictable results in case of different mirrors as well as you can't update test-servers and after all is fine two days later their production-buddy
- it is a useless burden for the mirror traffic
this script below works since many years and anybody who thinks /var/cache/yum/ is not important never had to maintain 10, 20, 30 or more Fedora machines
root@buildserver:~]$ cat /buildserver/repo-cache.sh #!/usr/bin/bash basearch=`uname -i` releasever=`rpm -q --qf "%{version}\n" fedora-release` for g in `ls -1b /var/cache/yum` do if [ -d /var/cache/yum/$g/packages ] then echo "/var/cache/yum/$g/packages/ > /repo/cache/fc$releasever/" sudo mv --verbose /var/cache/yum/$g/packages/*.rpm /repo/cache/fc$releasever/ 2> /dev/null fi done /buildserver/repo-create.sh
uhm "It has been disabled in Fedora and there has been no real use cases indicated" says who and with what real world expierience? look above!
the script above even caches presto-updates because the way YUM works the RPM is rebuilt in /var/cache/yum/ as like it would have been downloaded as a whole and in fact if the delta-rpm can't be downloaded for whatever YUM automatically downloads the full RPM at the same place which clearly shows that there was a lot of brainwork behind the way YUM acts
Reindl Harald wrote:
uhm "It has been disabled in Fedora and there has been no real use cases indicated" says who and with what real world expierience? look above!
They clearly haven't looked very far for use cases, indeed.
Another important use case (and another reason why keepcache=1 should not only be supported, but IMHO even be the DEFAULT): * Say an update to NetworkManager or one of its dependencies breaks your networking. (Maybe it's an unusual configuration that was missed during testing.) * Even ignoring the issue of mirrors not keeping old updates (which I already pointed out earlier in this thread), with networking not working, you simply CANNOT go to a mirror, directly to Koji etc. to get a downgrade. The ONLY place to get the old package from is your yum cache. * If this is not the first update to the package, you will definitely have the previous (or at least another recent) update cached. * If this IS the first update to the package, if (like me) you used the direct yum method to upgrade Fedora (and of course keepcache=1), you have the GA package cached. I don't know how FedUp handles this, but if it doesn't keep the cache, it should!
In that situation, with keepcache=0, the installation is BRICKED! With keepcache=1, it can be fixed by downgrading the offending package from the cache (rpm -Uvh --oldpackage).
Kevin Kofler
On 3 January 2014 04:32, Kevin Kofler kevin.kofler@chello.at wrote:
Reindl Harald wrote:
uhm "It has been disabled in Fedora and there has been no real use cases indicated" says who and with what real world expierience? look above!
They clearly haven't looked very far for use cases, indeed.
Another important use case (and another reason why keepcache=1 should not only be supported, but IMHO even be the DEFAULT):
- Say an update to NetworkManager or one of its dependencies breaks your networking. (Maybe it's an unusual configuration that was missed during testing.)
- Even ignoring the issue of mirrors not keeping old updates (which I already pointed out earlier in this thread), with networking not working, you simply CANNOT go to a mirror, directly to Koji etc. to get a downgrade. The ONLY place to get the old package from is your yum cache.
- If this is not the first update to the package, you will definitely have the previous (or at least another recent) update cached.
- If this IS the first update to the package, if (like me) you used the direct yum method to upgrade Fedora (and of course keepcache=1), you have the GA package cached. I don't know how FedUp handles this, but if it doesn't keep the cache, it should!
In that situation, with keepcache=0, the installation is BRICKED! With keepcache=1, it can be fixed by downgrading the offending package from the cache (rpm -Uvh --oldpackage).
Kevin Kofler
https://bugzilla.redhat.com/show_bug.cgi?id=1046244
-- 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 Fri, 03 Jan 2014 03:16:10 +0100, Reindl Harald wrote:
root@buildserver:~]$ cat /buildserver/repo-cache.sh #!/usr/bin/bash basearch=`uname -i` releasever=`rpm -q --qf "%{version}\n" fedora-release` for g in `ls -1b /var/cache/yum` do if [ -d /var/cache/yum/$g/packages ] then echo "/var/cache/yum/$g/packages/ > /repo/cache/fc$releasever/" sudo mv --verbose /var/cache/yum/$g/packages/*.rpm /repo/cache/fc$releasever/ 2> /dev/null fi done /buildserver/repo-create.sh
uhm "It has been disabled in Fedora and there has been no real use cases indicated" says who and with what real world expierience? look above!
Indeed, I have also made similar use of the yum cache (saved a lot of bandwidth usage).
This is the first time I heard of DNF. Looking at the page where differences between DNF and yum are explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question is: do we really need DNF to replace yum?
Maybe I'm wrong, but it seems to me that DNF is no more than yum with some different standard behavior and a couple of new command line options. So why replace yum? If those changes are good why simply don't change standard options in yum or add those new commands to yum?
Il 02/01/2014 16:28, Reindl Harald ha scritto:
look like it starts to happen again: a replacement which is not ready
https://lists.fedoraproject.org/pipermail/users/2014-January/444565.html https://lists.fedoraproject.org/pipermail/users/2014-January/444563.html
please realize that a drop-in replacement *first* needs to be *really* drop-in and not "somehow like", otherwise all the things you may make better are worthless
and yes "yum remove kernel" is a *minimum* to handeled properly
there are people maintaining RHEL5,RHEL6,RHEL7 and Fedora machines guess how abused they are if they have completly different behavior because dveleopers tend to call anything they don't like to implement a "border case"
On 01/04/2014 11:50 AM, Mattia Verga wrote:
This is the first time I heard of DNF. Looking at the page where differences between DNF and yum are explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question is: do we really need DNF to replace yum?
Maybe I'm wrong, but it seems to me that DNF is no more than yum with some different standard behavior and a couple of new command line options. So why replace yum? If those changes are good why simply don't change standard options in yum or add those new commands to yum?
That document, as the name implies, explains the current differences in *cli* behavior to yum, as in "things that might cause surprises for long-time yum users". Dnf doesn't exist to tinker with some cli differences just for the heck of it, the main reasons and goals have to do with the underlying depsolving engine and API, see eg
https://fedoraproject.org/wiki/Features/DNF#Detailed_Description https://lists.fedoraproject.org/pipermail/users/2014-January/444874.html
This and the other thread on fedora-users does make it clear that background and goals of dnf needs to be more clearly communicated though.
- Panu -
Il 04/01/2014 11:20, Panu Matilainen ha scritto:
On 01/04/2014 11:50 AM, Mattia Verga wrote:
This is the first time I heard of DNF. Looking at the page where differences between DNF and yum are explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question is: do we really need DNF to replace yum?
Maybe I'm wrong, but it seems to me that DNF is no more than yum with some different standard behavior and a couple of new command line options. So why replace yum? If those changes are good why simply don't change standard options in yum or add those new commands to yum?
That document, as the name implies, explains the current differences in *cli* behavior to yum, as in "things that might cause surprises for long-time yum users". Dnf doesn't exist to tinker with some cli differences just for the heck of it, the main reasons and goals have to do with the underlying depsolving engine and API, see eg
https://fedoraproject.org/wiki/Features/DNF#Detailed_Description https://lists.fedoraproject.org/pipermail/users/2014-January/444874.html
This and the other thread on fedora-users does make it clear that background and goals of dnf needs to be more clearly communicated though.
- Panu -
Thank you.
On Sat, Jan 4, 2014 at 5:37 AM, Mattia Verga mattia.verga@tiscali.it wrote:
Il 04/01/2014 11:20, Panu Matilainen ha scritto:
On 01/04/2014 11:50 AM, Mattia Verga wrote:
This is the first time I heard of DNF. Looking at the page where differences between DNF and yum are explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question is: do we really need DNF to replace yum?
Maybe I'm wrong, but it seems to me that DNF is no more than yum with some different standard behavior and a couple of new command line options. So why replace yum? If those changes are good why simply don't change standard options in yum or add those new commands to yum?
That document, as the name implies, explains the current differences in *cli* behavior to yum, as in "things that might cause surprises for long-time yum users". Dnf doesn't exist to tinker with some cli differences just for the heck of it, the main reasons and goals have to do with the underlying depsolving engine and API, see eg
https://fedoraproject.org/wiki/Features/DNF#Detailed_Description https://lists.fedoraproject.org/pipermail/users/2014-January/444874.html
This and the other thread on fedora-users does make it clear that background and goals of dnf needs to be more clearly communicated though.
- Panu -Thank you.
Inventing new paradigms is always painful. This one seems.... not really worth it. There's far more effective work that could be done with yum, for example improving the way yum handles "repodata" to to stop downloading such bulky files if they're actually altered in size and/or date, not merely if the cache is expired, to reduce wasted bandwidth and disk churn on virtualized clients.
Nico Kadel-Garcia wrote:
Inventing new paradigms is always painful. This one seems.... not really worth it. There's far more effective work that could be done with yum, for example improving the way yum handles "repodata" to to stop downloading such bulky files if they're actually altered in size and/or date, not merely if the cache is expired, to reduce wasted bandwidth and disk churn on virtualized clients.
The thing is, the default package managers we show to our users are all based on PackageKit, and using yum with PackageKit has always been a source of all sorts of trouble. The main issue is that yum only has a Python API. With dnf, PackageKit can skip the Python layer entirely and instead uses the underlying Hawkey library, which is written in C, directly. PackageKit being a C program, this is much more convenient and efficient. And all the stuff written in Python that currently uses the yum Python API is simply getting ported to the very similar dnf Python API. So API-wise, dnf should be making everybody happy.
Kevin Kofler
On Sat, 2014-01-04 at 10:50 +0100, Mattia Verga wrote:
This is the first time I heard of DNF. Looking at the page where differences between DNF and yum are explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question is: do we really need DNF to replace yum?
Maybe I'm wrong, but it seems to me that DNF is no more than yum with some different standard behavior and a couple of new command line options. So why replace yum? If those changes are good why simply don't change standard options in yum or add those new commands to yum?
Because yum's code is a mess. The primary point of the dnf rewrite is not to alter the user interface, but to clean up the code itself.
On 01/04/2014 03:09 PM, Adam Williamson wrote:
On Sat, 2014-01-04 at 10:50 +0100, Mattia Verga wrote:
This is the first time I heard of DNF. Looking at the page where differences between DNF and yum are explained (http://akozumpl.github.io/dnf/cli_vs_yum.html) my question is: do we really need DNF to replace yum?
Maybe I'm wrong, but it seems to me that DNF is no more than yum with some different standard behavior and a couple of new command line options. So why replace yum? If those changes are good why simply don't change standard options in yum or add those new commands to yum?
Because yum's code is a mess. The primary point of the dnf rewrite is not to alter the user interface, but to clean up the code itself.
That is great but it should support everything yum supported. Even Linux keeps old interfaces around, if they are going to change there is at least a period where they are marked as deprecated and with a caution they may be removed in the future!
On 04.01.2014 21:09, Adam Williamson wrote:
Because yum's code is a mess.
curl -s http://www.textfiles.com/art/monkey.vt
From Yum with Love.
poma
On Mon, 06 Jan 2014 16:30:20 +0100 poma pomidorabelisima@gmail.com wrote:
On 04.01.2014 21:09, Adam Williamson wrote:
Because yum's code is a mess.
curl -s http://www.textfiles.com/art/monkey.vt From Yum with Love.
poma
I don't think that helps
___ Regards, Frank www.frankly3d.com
Congratulations for lowering the level of this discussion even lower than it already was !
H.
On Thu, 02 Jan 2014 16:28:59 +0100 Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
https://bugzilla.redhat.com/show_bug.cgi?id=1049310
It seems the majority want the current dnf default [1] to be kept Those who want to keep "running" kernel may need to speak up [2]
[1] http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1049310
___ Regards, Frank www.frankly3d.com
On Jan 7, 2014 4:53 AM, "Frank Murphy" frankly3d@gmail.com wrote:
On Thu, 02 Jan 2014 16:28:59 +0100 Reindl Harald h.reindl@thelounge.net wrote:
look like it starts to happen again: a replacement which is not ready
https://bugzilla.redhat.com/show_bug.cgi?id=1049310
It seems the majority want the current dnf default [1] to be kept Those who want to keep "running" kernel may need to speak up [2]
[1]
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess.
-Toshio
On 01/09/2014 03:56 PM, Toshio Kuratomi wrote:
On Jan 7, 2014 4:53 AM, "Frank Murphy" <frankly3d@gmail.com mailto:frankly3d@gmail.com> wrote:
On Thu, 02 Jan 2014 16:28:59 +0100 Reindl Harald <h.reindl@thelounge.net
mailto:h.reindl@thelounge.net> wrote:
look like it starts to happen again: a replacement which is not ready
https://bugzilla.redhat.com/show_bug.cgi?id=1049310
It seems the majority want the current dnf default [1] to be kept Those who want to keep "running" kernel may need to speak up [2]
[1]
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-p...
After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess.
And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things.
Thanks, Jirka
-Toshio
Am 09.01.2014 16:03, schrieb Jiri Moskovcak:
After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess.
And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things.
in doubt in case of rewrites support the existing features and start the clean codebase with them in mind
On 01/09/2014 04:12 PM, Reindl Harald wrote:
Am 09.01.2014 16:03, schrieb Jiri Moskovcak:
After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess.
And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things.
in doubt in case of rewrites support the existing features and start the clean codebase with them in mind
And that is official Fedora (I mean respected by the community) rule or yours?
--Jirka
Am 09.01.2014 16:37, schrieb Jiri Moskovcak:
On 01/09/2014 04:12 PM, Reindl Harald wrote:
Am 09.01.2014 16:03, schrieb Jiri Moskovcak:
After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess.
And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things.
in doubt in case of rewrites support the existing features and start the clean codebase with them in mind
And that is official Fedora (I mean respected by the community) rule or yours?
mine - there is no "official" one and hardly will ever be
that is what a user normally expects: optimize things, add new features but do not demand him to change his workflow with no for the user obvious improvement
On 01/09/2014 04:40 PM, Reindl Harald wrote:
Am 09.01.2014 16:37, schrieb Jiri Moskovcak:
On 01/09/2014 04:12 PM, Reindl Harald wrote:
Am 09.01.2014 16:03, schrieb Jiri Moskovcak:
After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess.
And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things.
in doubt in case of rewrites support the existing features and start the clean codebase with them in mind
And that is official Fedora (I mean respected by the community) rule or yours?
mine - there is no "official" one and hardly will ever be
Well, but there will have to be one, at least when the time comes and dnf will proposed as default. At that point someone (fesco?) will have to evaluate it and vote and either accept it or refuse it. And as I see it, the decision will have to be based on some criteria, so I'm actually asking for this criteria to be revealed now so we can end this thread in piece and get back to work...
that is what a user normally expects: optimize things, add new features but do not demand him to change his workflow with no for the user obvious improvement
Well, I can use dnf in it's current shape quite fine and it works faster than yum which I take as an improvement, so for me it's ok. So what now?
--Jirka
On Thu, 09 Jan 2014 16:56:31 +0100 Jiri Moskovcak jmoskovc@redhat.com wrote:
Well, I can use dnf in it's current shape quite fine and it works faster than yum which I take as an improvement, so for me it's ok. So what now?
--Jirka
Then add your voice to the bz to keep it as is.
___ Regards, Frank www.frankly3d.com
On Thu, 09 Jan 2014 16:03:06 +0100 Jiri Moskovcak jmoskovc@redhat.com wrote:
And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things.
As we always have I think...
If the maintainer holds some position it's up to others to convince them to change their position, hopefully by providing facts and rational arguments.
If you can't convince them to your position, next you might try some kind of compromise solution if you can think of one.
If they don't change their mind and someone feels this is some issue that affects the entire distribution, they can ask FESCo to look into the matter and mediate or override the maintainer. Note however that FESCo very rarely overrides maintainers wishes.
kevin
-
Adam Williamson -
Ahmad Samir -
Alec Leamas -
Andrew Clayton -
Bill Nottingham -
Bob Arendt -
Chris Adams -
Chris Murphy -
Chuck Anderson -
Dan Mashal -
drago01 -
Dridi Boukelmoune -
Frank Murphy -
Gary Gatling -
Haïkel -
Ian Malone -
Jared K. Smith -
Jiri Moskovcak -
Jörn Rink -
Kevin Fenzi -
Kevin Kofler -
Lars E. Pettersson -
Luya Tshimbalanga -
Martin Langhoff -
Matthew Miller -
Mattia Verga -
Michael Scherer -
Michael Schroeder -
Miloslav Trmač -
Naheem Zaffar -
Nico Kadel-Garcia -
Panu Matilainen -
Petr Viktorin -
poma -
Przemek Klosowski -
Rahul Sundaram -
Reindl Harald -
Richard Hughes -
Richard Vickery -
Richard W.M. Jones -
SHERESSA HILL -
Stephen John Smoogen -
Steve Clark -
Till Maas -
Tomas Mlcoch -
Toshio Kuratomi -
Vít Ondruch -
yersinia -
Zoltan Boszormenyi