Hi All,
File dependancy should be counted like ref counting in gtk when a
program is added to the computer a reference count and a keyname is
added to a double-linked list in a system file then when the program is
removed the reference count for that dependent file is reduced by one,
when the coun
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 04.10.2013 15:34, Jan Zelený wrote:
If you have any other questions, comments or notes regarding the document,
feel free to to use this list for the discussion.
Where (list threads, wikis, sources) one should seek more details about
the DB aspects of the plan, e.g.:
* A1: Delta metadat
On 10/12/2013 10:58 PM, Reartes Guillermo wrote:
Maybe that can be enhanced to say "cset.uuid" instead of just "uuid" /
"set uuid"? (for which i confused it with dev.uuid shown by blkid,
since i never used bcache before).
cset.uuid can be obtained from the output of "bcache-show-super".
Cheers.
> 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 https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache
>> Note the set uuid and attach /dev/sdb1 to /dev/sda2: echo >
>> /sys/block/bcache0/bcache/attach
Maybe that can be enhanced to say "cset.uuid" instead of just "uuid" /
"set uuid"? (for which i confused it with dev.uuid shown by b
> 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
Dridi Boukelmoune wrote:
> My guesses:
> - there are other legal issues
> - interested parties missed/forgot it
> - interested parties are working on it
It's the first option. Both freetype and freetype-freeworld now include the
bytecode interpreter, which is indeed no longer patented (so the blo
> 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
Hello
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 package I want to remove. Recently I
On 10/12/2013 09:55 AM, Till Maas wrote:
On Tue, Oct 01, 2013 at 07:50:45PM +0200, Till Maas wrote:
cx18-firmware -- Firmware for Conexant cx23418-based video capture
devices
libcrystalhd -- Broadcom Crystal HD device interface library
lirc -- The Linux Infrared Remote Control package
rinputd -
> Date: Sun, 6 Oct 2013 21:03:36 -0700
> From: Dave Johansen
> To: Development discussions related to Fedora
>
> Subject: Re: boost141 and stability of Boost API?
> Message-ID:
> wyne8tgs4m-zr8cc1hs45bg9pmn...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> O
On 10/12/2013 09:55 AM, Till Maas wrote:
[cut]
The packages are now orphaned, so please pick them up.
Regards
Till
I have picked lirc.
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.
On Tue, Oct 01, 2013 at 07:50:45PM +0200, Till Maas wrote:
> cx18-firmware -- Firmware for Conexant cx23418-based video capture
> devices
> libcrystalhd -- Broadcom Crystal HD device interface library
> lirc -- The Linux Infrared Remote Control package
> rinputd -- A server for receiving input eve
On Thu, Oct 10, 2013 at 03:12:51PM +0200, Alec Leamas wrote:
> I've been wating a little for raveit to respond, but none so far.
> Since I actually have spent some time on this already, I can take
> this package if it's OK with everyone.
It looks like Jarod orphaned all of his packages, so you ca
35 matches
Mail list logo
