> On Tuesday, 15 October 2013 12:51 PM, Jan Zelený wrote:
> Even though yum might handle the resolution a little better (and dnf probably
> will do that, feel free to check it), the ultimate culprit here is a very
> poor
> packaging and both dnf and yum have only a limited set of options what t
On 15. 10. 2013 at 04:33:08, P J P wrote:
> > On Monday, 14 October 2013 8:05 PM, Eric H. Christensen
> > wrote: I believe he is assuming that xchat has
> > a direct relationship with bluez which, I'm guessing here as I haven't
> > checked, probably isn't the case. Because bluez affects something
> On Monday, 14 October 2013 8:05 PM, Eric H. Christensen
> wrote:
> I believe he is assuming that xchat has a direct relationship with bluez
> which,
> I'm guessing here as I haven't checked, probably isn't the case.
> Because bluez affects something that xchat depends on xchat is getting th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, Oct 12, 2013 at 02:31:37PM -0500, Bruno Wolff III wrote:
> On Sun, Oct 13, 2013 at 03:13:41 +0800,
> P J P wrote:
> >
> > No, it does not. If yum is protecting users from un-installing a package
> >which could render the whole system un
Am 12.10.2013 22:53, schrieb P J P:
>> On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III wrote:
>> Your example of removing kernel is even more esoteric. Fedora wouldn't
>> work at all without it.
>
> Well, kernel one works when there are multiple kernels installed. It
> happens when yu
Am 12.10.2013 23:32, schrieb P J P:
>> On Sunday, 13 October 2013 1:47 AM, Reindl Harald
>> wrote:
>> *bullshit* you have no clue what the result of a specific broken dependency
>> would be nor have yum, dnf or even god
>
> Well, when no-one has a clue, assuming the worst is just _one_ way of
Am 12.10.2013 22:00, schrieb P J P:
> That is why it is okay to let user remove package 'bluez'
[harry@srv-rhsoft:~]$ rpm -qa | grep bluez
bluez-libs-4.101-9.fc19.x86_64
[harry@srv-rhsoft:~]$
as you can see yum or dnf *are not* responsible
ask gnome-upstream why they are too stupid to run withou
Am 12.10.2013 22:00, schrieb P J P:
>> On Sunday, 13 October 2013 12:50 AM, Reindl Harald
>> wrote:
>> there is no if and but if a package has a dependency than it has one - period
>
>Sure, it has dependency. That does not make it an _absolutely_ requirement
> to have a functional system.
Am 12.10.2013 19:34, schrieb P J P:
>> On Saturday, 12 October 2013 10:43 PM, Reindl Harald
>> wrote:
>> *why* should it be addressed in yum or DNF?
>>
>> if a package pulls un-needed dependencies the package has
>> to be fixed and *not* worked around it - period
>
> Yes, agreed. But that mi
Am 12.10.2013 18:42, schrieb P J P:
> It is an often experience that I try to remove a package(ex: bluez, kernel,
> gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of
> critical packages, which has no connection(ex. kernel => Xchat OR bluez =>
> gedit etc.) with the p
Am 12.10.2013 19:00, schrieb P J P:
>> On Saturday, 12 October 2013 10:19 PM, Reindl Harald
>> wrote:
>> that's why i get that mad if packagers careless add new deps because
>> they enable whatever function in a package instead split the new
>> ones in additional subpackages
>
> I see. If it i
Am 12.10.2013 20:16, schrieb P J P:
>> On Saturday, 12 October 2013 11:23 PM, Reindl Harald
>> wrote:
>> if you want get a feeling in what these ends type the follwoing as root
>> after you prepeared a rescue-disc because not rpm, nor yum nor even sshd
>> will work any longer and you need to co
Am 12.10.2013 21:13, schrieb P J P:
>> On Sunday, 13 October 2013 12:04 AM, Reindl Harald
>> wrote:
>> and your "list possible affected packages but allow me to remove" ends
>> *exactly* there
>
> No, it does not. If yum is protecting users from un-installing a package
> which could render t
Am 12.10.2013 20:20, schrieb Bruno Wolff III:
> On Sun, Oct 13, 2013 at 00:42:43 +0800,
> P J P wrote:
>>
>> It is an often experience that I try to remove a package(ex: bluez, kernel,
>> gnome-bluetooth) and yum(8) prompts
>> me to remove nearly 200-300MB worth of critical packages, which ha
> On Sunday, 13 October 2013 1:47 AM, Reindl Harald
> wrote:
> *bullshit* you have no clue what the result of a specific broken dependency
> would be nor have yum, dnf or even god
Well, when no-one has a clue, assuming the worst is just _one_ way of doing
things.
> says who?
> in case of b
On Sun, Oct 13, 2013 at 04:53:48 +0800,
P J P wrote:
On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III wrote:
Your example of removing kernel is even more esoteric. Fedora wouldn't
work at all without it.
Well, kernel one works when there are multiple kernels installed. It happens
w
> On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III wrote:
> Your example of removing kernel is even more esoteric. Fedora wouldn't
> work at all without it.
Well, kernel one works when there are multiple kernels installed. It happens
when yum installs a new kernel update. Each kernel bri
On Sun, Oct 13, 2013 at 04:00:58 +0800,
P J P wrote:
Does that mean gnome-shell, xchat & gthumb can not function without package
bluez? No. It means dependency relationship is broken.
In the eyes of the gnome developers the answer is no, it won't work properly
without bluez. That's why th
> On Sunday, 13 October 2013 12:50 AM, Reindl Harald
> wrote:
> there is no if and but if a package has a dependency than it has one - period
Sure, it has dependency. That does not make it an _absolutely_ requirement
to have a functional system. Because the dependency relationship could be
On Sun, Oct 13, 2013 at 03:13:41 +0800,
P J P wrote:
No, it does not. If yum is protecting users from un-installing a package
which could render the whole system unusable or unresponsive, what remains is
not-so important packages, which pull in 100 other _unrelated_ packages to the
list
> On Sunday, 13 October 2013 12:04 AM, Reindl Harald
> wrote:
> and your "list possible affected packages but allow me to remove" ends
> *exactly* there
No, it does not. If yum is protecting users from un-installing a package
which could render the whole system unusable or unresponsive, wha
On Sun, Oct 13, 2013 at 00:42:43 +0800,
P J P wrote:
It is an often experience that I try to remove a package(ex: bluez, kernel,
gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical
packages, which has no connection(ex. kernel => Xchat OR bluez => gedit etc.
> On Saturday, 12 October 2013 11:23 PM, Reindl Harald
> wrote:
> if you want get a feeling in waht these ends type the follwoing as root
> after you prepeared a rescue-disc because not rpm, nor yum nor even sshd
> will work any longer and you need to copy the package files by hand
> to their loc
> On Saturday, 12 October 2013 10:43 PM, Reindl Harald
> wrote:
> *why* should it be addressed in yum or DNF?
>
> if a package pulls un-needed dependencies the package has
> to be fixed and *not* worked around it - period
Yes, agreed. But that might probably involve fixing the package review
On 10/12/2013 10:11 AM, P J P wrote:
On Saturday, 12 October 2013 10:31 PM, Samuel Sieb wrote:
If there's a bug, then this is it. You should not be able to remove bluez
because there are dependencies on it.
Well, remove_leaf_only=1 restricts dependency resolution to the leaf nodes
only,
> On Saturday, 12 October 2013 10:31 PM, Samuel Sieb wrote:
> If there's a bug, then this is it. You should not be able to remove bluez
> because there are dependencies on it.
Well, remove_leaf_only=1 restricts dependency resolution to the leaf nodes
only, that is why it allows removing blu
On 10/12/2013 09:42 AM, P J P wrote:
===
Package Arch Version
Repository Size
==
> On Saturday, 12 October 2013 10:19 PM, Reindl Harald
> wrote:
> that's why i get that mad if packagers careless add new deps because
> they enable whatever function in a package instead split the new
> ones in additional subpackages
I see. If it is a packaging error, how does DNF plan to ad
28 matches
Mail list logo
