On Mon, Apr 11, 2016 at 2:30 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> This moves those macros under the maintenance of the rpm team.
> I guess this could work for a few projects, let's say perl and python,
> but I don't see how this can scale (to perl, python, java, js, lisp,
Orion Poplawski píše v Po 11. 04. 2016 v 09:11 -0600:
> On 04/11/2016 07:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > Hi,
> >
> > On Fri, Apr 01, 2016 at 01:45:15PM +0200, Tomas Chvatal wrote:
> > >
> > > Atm most of the macros are stored together with the packages they
> > > are
> > >
Hi,
On Fri, Apr 01, 2016 at 01:45:15PM +0200, Tomas Chvatal wrote:
> Atm most of the macros are stored together with the packages they are
> used for (kde macros in kde, systemd in systemd, python in python, etc
> etc).
...and that sounds just right. Macros should evolve along with their
On Mon, Apr 11, 2016 at 12:53:35PM +0200, Michael Mraka wrote:
> So to make things consistent I'd propose to fix
> rpm -q --whatrequires H
> which currently returns "none". And fix --whatsuggests, --whatrecommends, etc.
> to work the same way.
Wait, don't make "rpm -q --whatrequires H" return
Thank you guys for your responses.
Not surprisingly - different people, different expectations :).
Miroslav Suchy wrote:
% In rpm I would like to have semantic "which package will stop working if I
remove this package".
% I.e. when I run:
% rpm -e foo
% then I will get some errors that foo