[repo-coord] Re: Practice, use, design and implementation of rpm

[Axel Thimm]

I think this platform is rpm-devel, if enough (different) distributers
are around. More than discussing implementation we should reconsider
the basic design especially in light of multiple distributions (both
in the same upgrade line, as well as non-mixable distributions).

So consider away. I am not stopping you. I merely ask that you
discuss how to package, and how to use rpm-python, and how to create
distros, etc elsewhere.
This list is for rpm internal development, and coordinating rpm
deployment with distros that use rpm, not otherwise.
Hey, it's my list, I reserve the right to say
Mornington Crescent!
at any time. ;-)

OK, no problem, I got carried away with "RPM internals development and
distro coordination", so I thought we have a good platform for getting
the different abuses of rpm in various distributions on one table and
sort them out (with the target to identify whether there is anything
that really needs new implementation, and ow to carefully design it).

Anyway, I invite anyone who isn't yet on repo-coord to continue such
discussions there, and reduce the noise here :)

http://lists.atrpms.net/mailman/listinfo/repo-coord

repo-coord was originally intended for 3rd party RH/FC repos, but the
same issues apply to larger rpm worlds than RH/FC, and getting
cross-distribution compatibility and standards is a very nice topic to
fill repo-coord with :=)

If/When repo-coord comes to any good suggestions on rpm extensions, we
can summarize the outcome and present it here :)

(FollowUps sent to repo-coord)

[Jeff Johnson]

Post by Axel Thimm

I think this platform is rpm-devel, if enough (different) distributers
are around. More than discussing implementation we should reconsider
the basic design especially in light of multiple distributions (both
in the same upgrade line, as well as non-mixable distributions).

So consider away. I am not stopping you. I merely ask that you
discuss how to package, and how to use rpm-python, and how to create
distros, etc elsewhere.
This list is for rpm internal development, and coordinating rpm
deployment with distros that use rpm, not otherwise.
Hey, it's my list, I reserve the right to say
Mornington Crescent!
at any time. ;-)

OK, no problem, I got carried away with "RPM internals development and
distro coordination", so I thought we have a good platform for getting
the different abuses of rpm in various distributions on one table and
sort them out (with the target to identify whether there is anything
that really needs new implementation, and ow to carefully design it).
Anyway, I invite anyone who isn't yet on repo-coord to continue such
discussions there, and reduce the noise here :)
http://lists.atrpms.net/mailman/listinfo/repo-coord
repo-coord was originally intended for 3rd party RH/FC repos, but the
same issues apply to larger rpm worlds than RH/FC, and getting
cross-distribution compatibility and standards is a very nice topic to
fill repo-coord with :=)
If/When repo-coord comes to any good suggestions on rpm extensions, we
can summarize the outcome and present it here :)
(FollowUps sent to repo-coord)

NP. Bring me consensus, show me proof-of-concept, and I'll be happy to
add to rpm.

It's way easier to hack rpm than it is to sort through the morass of
competing viewpoints
like Disttag: and Suggests: and what apt is doing and whether mach is
better or worse
than beehive, or whether conary is the cat's pajamas or just another
crazy idea.

So don't be annoyed, I'm just trying to focus on hacking rpm here, not
set up Yet Another
petty fiefdom.

Mine! rpm is all mine! ;-)

/me cackles as he goes off to lick his toad ...

BTW, "Mornington Crescent!" is heartily recommended to one and all:
http://www.isihac.co.uk/games/mcvariations/index.html
and the BBC disks are even more fun.

Thanks Paul!

73 de Jeff

[Jeff Pitman]

Post by Axel Thimm
If/When repo-coord comes to any good suggestions on rpm extensions,
we can summarize the outcome and present it here :)

So, where do we go from here? Past discussion points really have never
been driven to a consensus. Good arguments have been presented but
we've never driven across a consistent front on the issues. I realize
some of these things may take time as more and more implementations are
out in the wild.

I'd like to see a common strategy set forth on:

1. disttag naming (rh* vs. 1.fc2, etc.)

2. vendor tag

3. packager tag

4. distribution tag

5. distro detectors for %if

6. ... more stuff here ...

I know the arguments for #1.

Morten brought up some ideas for #2 through #4.

I sent in a piece on the mach list about detecting distros wrt #5 and
many shot it down as being the wrong way to do things. And, now the
issue is brought up as being useful for rebuilding src.rpms.

Although my repo is still in the testing phase, its release we'll see
packages for legacy Redhat, Fedora, and SuSE 9.1. The issues I've run
into have been interesting to say the least and dealing with
BuildRequires, etc. would be a lot easier than relying on hand hacking
comments in the spec files.

I believe the ultimate achievement of consensus would be able to codify
this into a succinct document containing signatories, "Axel, Dag,
Dries, Fernando, Link, Matthias, Rex, Rudolf, et al". It could even
have a section called "Here's How We Hack RPM Now; But, Here's How It
Could Change To Make It Mucho Better".

Discuss away! ;-)

take care,

[Axel Thimm]

Post by Jeff Pitman

Post by Axel Thimm
If/When repo-coord comes to any good suggestions on rpm extensions,
we can summarize the outcome and present it here :)

So, where do we go from here? Past discussion points really have never
been driven to a consensus. Good arguments have been presented but
we've never driven across a consistent front on the issues. I realize
some of these things may take time as more and more implementations are
out in the wild.

The good news are that the differences were on the implementation side
of what to put into disttags, not about disttags themselves.

So while it has become rather accepted by many parties to have

foo-1.2.3-<buildid><opt_repotag>.src.rpm
foo-1.2.3-<buildid><disttag><opt_repotag>.<arch>.rpm

the contents of disttag have been varying. But for extending rpm to
allow the above scheme you don't need to know how the disttag will
look like on distribution XYZ.

In light of defining something larger than our rim of the teacup
(e.g. not only for the one or two distributions we are personally
focusing at) these difference become refinements, and we may have an
easier going if we keep things more abstract at the beginning
(e.g. not discussing my-favourite-scheme).

I think many of the past arguments will become more evident as we do a
top-down approach and we will finally have better grounds for
convergence.

What would be nice to achieve is to get representatives from the major
distributions. Most people on repo-coord are RH/FC only. It would also
help if before emerging new strategies the different distributions
would lay out their current schemes and workarounds.