package, package2, package3 naming-with-version exploit

[Miloslav Trmač]

On Thu, Apr 4, 2013 at 3:16 PM, Vít Ondruch <vondruch at redhat.com> wrote:

>  Dne 3.4.2013 18:15, Miloslav Trmač napsal(a):
>
>  On Wed, Apr 3, 2013 at 5:02 PM, Vít Ondruch <vondruch at redhat.com> wrote:
>
>>  Dne 3.4.2013 15:59, Miloslav Trmač napsal(a):
>>
>> On Wed, Apr 3, 2013 at 3:22 PM, Vít Ondruch <vondruch at redhat.com> wrote:
>> ... and now, can we be specific? No handwaving, how would parallel
>> installation _actually_ benefit you?  How would the new system look like
>> and work?
>>
>>
>>> Now, there comes security fix for Rails. Typically it impacts every
>>> stable Rails branch, i.e. it should be applied to two packages. But you
>>> already denied me to use cherry-pick straight forward, since I am not
>>> working with one package/repository but with two packages. So again more
>>> work then it necessarily needed to be.
>>>
>>
>>  I can't see that parallel installation would help.  Because there would
>> be one git repo for all versions?  That's orthogonal to having parallel
>> installation of RPMs.
>>
>>
>>  Yes, they would be in one git repo with single maintainer (or group of
>> maintainers).
>>
>
>  AFAICS that is a Fedora dist-git concern that is completely unrelated to
> parallel installation.  Fedora dist-git could support a single git repo for
> multiple packages (with different names) without rpm supporting parallel
> installation.
>
>
> 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.

  Actually then somebody comes and he things that he doesn't need just
>> Rails 3.0, but he needs specifically Rails 3.0.5, so he well do another new
>> package rails305. You cannot stop this explosion of various versioned
>> modules.
>>
>
>  Yes, you cannot.  How is that different in the case where rpm
> supports/doesn't support parallel installation?
>
>
> There might be defined upgrade path, i.e. you might be able to define that
> your branch is for Rails 3.0. In RubyGems, we would define it as as ~>
> 3.0.0 dependency [1].
>

Now I can define it using the package name, and even modify it later using
Obsoletes:/Provides:.

     I can't see that parallel installation would help.  We need to create
>> and maintain as many packages as users require in either case.
>>
>>  It would help, since I could focus on packaging new rails version
>> instead of fixing compatibility issues of current applications in Fedora
>> with the framework they use.
>>
>
>  The two are again, AFAICS, completely orthogonal to parallel
> installation support.  Instead of fixing compatibility issues the current
> applications could just depend on rails23 or something.  Not having
> parallel installation does not automatically compel anyone to port
> applications; this is primarily determined by Fedora policy/preference and
> Fedora tooling, not rpm limitations.
>
>
> You cannot think about parallel installation without broader scope. You
> might find a lot of orthogonal things in this issue. Something is RPM
> issue, something else YUM, something else Fedora policies. This gives
> always freedom to claim that it could be done differently, not in my
> component etc.
>

Well, sure, what Bohuslav said.  Some people want Fedora to accept such RPM
packages, some people want RPM support, some people might even want Fedora
to ship unmodified gems/jars/eggs without RPM.


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.

That doesn't prevent us from discussing RPM features that Fedora wouldn't
use (but might be useful for coprs and RHEL).  It also doesn't prevent us
from discussing running of unmodified upstream packages on a Fedora
system.  But we need to distill what the goals of the discussion and the
_actual requirements_ are.

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.
    Mirek


P.S. I'll grant you that putting versions into the %{name} field is
unclean, but I really can't see that as a significant problem - I guess
%{name}, %{version} and %{release} could be named %{Tom}, %{Dick} and
%{Harry} for all we care and we would be able to get by (after all, we can
handle names like /bin/ls :) ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130404/b72995e1/attachment.html>