Re: [Rpm-ecosystem] Sync of rpm macros between Fedora/openSUSE

[Neal Gompa]

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, mono,
> swift, node, ocaml, octave, php, R, ruby, tcl, etc, etc, etc).
> RPM should instead provide a featureful base upon which individual
> projects can build.
>

I think the assumption here is that you could use it as a base to
start from, and that regular merging would occur.

For example, Fedora and SUSE both have GitHub organizations. The RPM
organization repository containing these macros could be forked by
both organizations. From there, each distribution would apply their
own changes to suit their needs. In addition, they can push changes
back upstream through a pull request and regularly resync with master.
This makes it much easier to keep compatibility closer together.

This mechanism would make it easy for existing distributions and new
distributions to be able to properly source what they need to support
a wide variety of software as RPM packages.

It would also keep us from sacrificing speed for compatibility, as the
distributions would be regularly forking and merging for their own
distributions.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Sync of rpm macros between Fedora/openSUSE

[Tomas Chvatal]

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
> > > 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
> > projects. Moving them to rpm or some central repository just
> > needlessly ties their lifecycle to something external and makes it
> > harder for people who are specialists in a given area to evolve the
> > macros.
> > 
> > And moving things out of their upstream projects moves things away
> > from your stated goal: after all the distributions share the same
> > upstreams,
> > so if the projects' macros are used, they are identical in all
> > distributions.
> > At least for systemd keeping the macros upstream and simply
> > including
> > them in systemd.rpm works nicely. This model might not work for
> > some
> > upstream projects like Python because of their long release cycle.
> > In those cases there could be a sub-project just for the macros,
> > living
> > a life of it's own, possible shared between distributions. Would
> > http://pkgs.fedoraproject.org/cgit/rpms/python-rpm-macros.git/
> > be useful for SUSE?
> > 
> > Zbyszek
> > 
> But the problem is that they generally live in the downstream distro
> packages
> as most upstreams don't particularly care about rpm
> packaging.  Although I
> agree that from a distro point of view splitting the macros out to
> the
> packages is the most appropriate.
> 
> I'm not sure we need any particularly formal release process for this
> so I
> think something like:
> 
> rpm-macros/python/
>   /perl/
>   /.../
> 
> And then the distro package just update their copies as needed.
> 
> Or perhaps the python-rpm-macros could serve as a template for cross-
> distro
> domain specific macros packages.
> 
I would shoot for idea where the bla.macros would just sit in git and
the packages would specify as sources the macros ie.:
Source99: https://github.com/rpm/rpm-macros/archive/python.macros

Then the downstreams could just refetch the sources to get the newer
macros as needed.

I don't think we could sell the idea that all macros live in one huge
package or if they are split, most people would complain and expect
them to be delivered either with main package or with -devel package.

Tom

signature.asc
Description: This is a digitally signed message part
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Sync of rpm macros between Fedora/openSUSE

[Zbigniew Jędrzejewski-Szmek]

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
projects. Moving them to rpm or some central repository just
needlessly ties their lifecycle to something external and makes it
harder for people who are specialists in a given area to evolve the
macros.

And moving things out of their upstream projects moves things away
from your stated goal: after all the distributions share the same upstreams,
so if the projects' macros are used, they are identical in all distributions.
At least for systemd keeping the macros upstream and simply including
them in systemd.rpm works nicely. This model might not work for some
upstream projects like Python because of their long release cycle.
In those cases there could be a sub-project just for the macros, living
a life of it's own, possible shared between distributions. Would
http://pkgs.fedoraproject.org/cgit/rpms/python-rpm-macros.git/
be useful for SUSE?

Zbyszek

> I would suggest we create some common repository to contain these
> and slowly merge them in. After all the packages can then download
> files from this repository quite fine and we can still keep the
> modularity of not having to put all the macros to rpm or to have some
> package like rpm-macros-blob containing everything.
> 
> Because as we did this already once in past it worked for a bit but
> then we started to diverge a lot again. With common repository we could
> accomodate for most needs and actually make it work.
> 
> Ie. we at SUSE have multiple ruby implementations so we have overbroad
> macros for that, but there is no reason why those macros could not
> understand RH system and use simplified values for that and vice-versa
> in other scenarios.
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm -q --whatrequires and rich deps

[Michael Schroeder]

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 richdep if richdep
contains
Requires: (G if H else I)

The H package is on the "if" side, so it is not required. Either
G or I is required. Putting H in the requires index (that's what
you propose) will just mess up rpm's dependency solving.

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm -q --whatrequires and rich deps

[Michael Mraka]

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 cannot be removed because A,B and C 
requires it.
% I would expect that --whatrequires gives me the same list (sans transitive 
requires).

James Antill wrote:
%  In general I'd say it's pretty confusing to return something that's a
% requirement of what's installed, but the thing that's required isn't
% installed (and doesn't need to be). So while you can kind of explain
% away why it's shown, it will be less useful and confusing to do so.

This is one of the possible semantics, let's call it "strict".

Michael Schroeder wrote:
% The current implementation returns packages that *potentially* break
% if the package is deinstalled.

Which is kind of opposite "loose" semantic - which packages have this dependency
mentioned among its requires (in any expression).

% >   richdep.spec:
% > Requires: A
% > Requires: B
% > Requires: (C and D)
% > Requires: (E or F)
% > Requires: (G if H else I)
% >

Seems that we all agree following

rpm -q --whatrequires A
rpm -q --whatrequires B
rpm -q --whatrequires C
rpm -q --whatrequires D
rpm -q --whatrequires '(C and D)'
rpm -q --whatrequires '(E or F)'
rpm -q --whatrequires '(G if H else I)'

should definitely output "richdep". I also think we can agree that

rpm -q --whatrequires '(G if H)'

should output nothing as it's neither a single dependency nor an exact
expression.

And for the rest

 rpm -q --whatrequires E
 rpm -q --whatrequires F
 rpm -q --whatrequires G
 rpm -q --whatrequires H
 rpm -q --whatrequires I

it depends on which strategy we will agree. It's either "richdep" for
loose one or for strict one it depends on current rpmdb status.

Here is couple of reasons why I'd prefer "loose" semantic:

- Currently if there is a package with broken dep A (e.g. installed with
  rpm --nodeps) then --whatrequires A reports it.
- Weak deps --whatsuggests, --whatrecommends, etc. As weak deps can naturally
  be unsatisfied and that's correct, the answer for 
rpm --whatsuggests A
  should report possible breakage not the currently installed packages.
- And then there's dnf where 'dnf repoquery --whatrequires' also should report
  all (possibly) broken packages.

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.


--
Michael Mráka
Software Management Engineering, Red Hat

___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem