On Thu, Apr 4, 2013 at 4:12 PM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 4.4.2013 15:47, Miloslav Trmač napsal(a):
On Thu, Apr 4, 2013 at 3:16 PM, Vít Ondruch <vondruch(a)redhat.com> wrote:
> Since .spec file is named the same as package, then you cannot merge
> straight forward the changes from one package into another.
>
That is again a Fedora policy, not a RPM requirement.
Ok, so shall I read it an "go ahead, and propose Fedora policy change,
that although package name includes version, the .spec file should be named
without the version."?
(I can't speak for the FPC.) If it would actually save you work (within
the context of other existing policies that discourage multiple versions),
sure, it's at least worth discussing. If you don't need it as such, and
would only need it with widespread support for parallel installation, I
can't see the benefit right now.
As you probably already know, there is fairly strong resistance
against Fedora shipping many versions because some of as feel that
we
wouldn't be able to maintain them properly.
I feel that we do so and we are not able to maintain it properly. So there
would not be any change in this regard.
Yes, I have the same worry. However my conclusion from this is that we
shouldn't make a bad situation worse - in particular, it might be good if
it were easier to become a Fedora "packager" by helping comaintain a
critical package than by packaging an obscure package that nobody wants to
use.
If you need Fedora policy to support multiple versions, and don't care
about RPM, please say so.
If you need RPM to support multiple versions, and don't care about
Fedora policy, please say so (and suggest practical semantics for (yum
update)).
If you need unmodified upstream deployment systems and unmodified
upstream packages with minimal Fedora/RPM interference/involvement, please
say so.
You've argued for RPM support, but it seems that the difficulties you
actually encounter are related to Fedora policies, and I wanted to make
that clear.
That's both, RPM and Fedora plolicies and don't forget about YUM. They are
not independent.
You've been offered a technical alternative to your desired RPM changes,
and AFAICS it fulfills all your requirements except for what I consider
esthetics.
Mirek