package, package2, package3 naming-with-version exploit

[Miloslav Trmač]

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:
>
>> Ok, so lets say we introduce the rails23 compatibility packages (which is
>> IMO the better option, since the nonversioned package should always point
>> to newest and greatest release), we do the reviews and we possibly double
>> the amount of packages. We even fix all the application dependencies from
>> rubygem-rails to rubygem-rails23.
>
>
>  OK, let's skip the re-reviews.  That's obviously added work.
>
>
>  ... 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.


Current Rails are maintained, I don't consider to be big headache to
> maintain more branches, but it gets complicated to maintain multiple
> components.
>

Where is the difference, and more importantly how does it depend on rpm
support?  AFAICS this is again a Fedora dist-git (and Fedora package
review) concern.


Yes, you might change the policy that re-reviews are not necessary, but
> anyway, you'll end up with mess of packages such as rails23, rails30,
> rails31, rails32, rails40 and you lost the meaning of version.
>

Who cares?  In what case?  Is that only about the '-' character?


> 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?


>   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.
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130403/e0064b83/attachment.html>