package, package2, package3 naming-with-version exploit

Thu Apr 4 13:16:44 UTC 2013

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 
> <mailto: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
>>     <mailto: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.

Since .spec file is named the same as package, then you cannot merge 
straight forward the changes from one package into another. In one repo 
you would have foo.spec file and in another foo1.spec file, so be it one 
or two repositories, you would need to do the merge by yourself.

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

See above.

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

That is about semantics.

Package name should be the same as upstream name, there are definitely 
no project such as rails23 or rails 30. So you confuse your users. And 
then, there is no implied relation for such packages. There might be for 
you, but it gets harder for machines. Actually rpm5 is different project 
then RPM we are using in Fedora.

You loose the meaning of version field as well. Where can I found the 
rails23-1.0 version of package? Why the first available version of 
rails23 is -2.3.0 and the last -2.3.8, upstream does not release new 
versions? That's odd. What if there will be release Rails 2.4 and 
somebody even update the rails23 package to rails-2.4.0 version? And 
don't tell me that this cannot happen, take look on Linux kernel which 
changed its version to 3.x basically just because of fun. May be the 
upstream is using string comparision for versions, so they cannot 
release Rails 2.3.10 (this is btw case of Ruby, i.e. the versions must 
be comparable in its string representation).

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

Yes, still, somebody could come and do review of rails305 anyway, but it 
would be visible as a exception.

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

Actually, if packages are nonconflicting, RPM itself can install them 
side by side without any issues. That would mean that RPM buys should 
not be involved. So now we can blame YUM, you things that we can solve 
it by policy and renaming packages. So at this point, we might say that 
renaming packages is not what we want. Ok, get back to YUM, YUM would do 
something but RPM is completely fine, since it can install several 
nonconflicting packages, so why there should be any additional metadada 
or what else might be needed, if it is possible already.

We can play this game forever.

Vít

[1] http://docs.rubygems.org/read/chapter/16#page74
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130404/4d213c8d/attachment-0001.html>