On 01/26/2014 12:18 PM, Heiko Adams wrote:
Am Sonntag, den 26.01.2014, 12:14 +0100 schrieb Lars E. Pettersson:
...
Would it not be better to have a 'software center' that includes ALL
software available, be they GUI related or not? Probably based on
rpm-packages, as that is what
plication' correlates to a rpm-package?
Application means GUI application that has a .desktop file.
That makes the 'software center' of lesser use, as the user will be
confused when he/she does not find the program/rpm-package/application
he/she wants to install.
Lars
--
Lars
ng something obvious here?
How does 'application' correlates to a rpm-package?
Lars
--
Lars E. Pettersson
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
umentation, 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
--
Lars E. Pettersson
http://www.sm6rpz.se/
--
devel mailing list
d
cumentation. He/she should not
need to try things, they should be documented, if they are not
documented, then it is a documentation bug.
Lars
--
Lars E. Pettersson
http://www.sm6rpz.se/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/deve
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 obviou
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
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 mentio
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&
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
e 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 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, no
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
On 01/05/2014 12:02 PM, Dridi Boukelmoune wrote:
On Sun, Jan 5, 2014 at 10:27 AM, Lars E. Pettersson 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 ali
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
--
Lars E. Pettersson
http://www.sm6rpz.se/
--
devel mailing list
devel@lists.fedoraproject
be spared, in my opinion.
<https://bugzilla.redhat.com/show_bug.cgi?id=976704>
Lars
--
Lars E. Pettersson
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
Transaction Summary
Upgrade 19 Packages
The updates were successfully applied
--
Lars E. Pettersson
http://www.sm6rpz.se/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
o the person in charge on that computer. Perhaps this should be
mentioned in the installation guide or something, or even done in anaconda?
Lars
--
Lars E. Pettersson
http://www.sm6rpz.se/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
haps a bad
thing to clog up the logs with that?
Lars
--
Lars E. Pettersson
http://www.sm6rpz.se/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
19 matches
Mail list logo
