package, package2, package3 naming-with-version exploit

[Florian Festi]

On 04/03/2013 05:02 PM, Vít Ondruch 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
>>     That looks quite simple, but you doesn't count that what is called
>>     Ruby on Rails is collection of 40 packages (the number vary from
>>     version to version, but tends to increase), which would need to be
>>     re-reviewed, although they were just perfect moment ago.

Sorry, but the rpm developers are the wrong people to talk to when it
comes to Fedora packaging policies.


>>
>>     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.
No, you should just add an virtual provide for rubygem-rails = 2.3.x You
might still need to fix your applications as they most likely won't run
with Rails 3 but not requiring rubygem-rails < 3 but that's another problem.


> Yes, they would be in one git repo with single maintainer (or group of
> maintainers). Although it does not ensure much, there is higher chance
> that the package will be consistent, i.e. that security fix will be
> applied in all branches. You can use all nice git features to easy your
> work.

I had rather expected that not having the two versions in the same tree
is an advantage as it allows different people to step in without messing
with the main package.


You somehow assume that just because we add some magic in rpm things in
Fedora change dramatically. I see no reason why creating a new version
should be any easier than creating a new package. With some work (and
surely less than needed for your proposal) on the build system forking
off a package with a new name could be as simple as any other solution.

The same is true for the git trees. Implementing a way of moving some
patches between different trees and packages is much easier than making
multiple versions out of one tree work. This can probably even be done
locally without asking anyone within Fedora.

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

I got that you really, really, really don't like the package names. But
the number of packages is actually exactly the same as with your own
proposal. Yes, it is ugly to have all those different packages - but
this is what you are asking for. The fact that they all share the same
name do not reduce their numbers.

> 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. That would be application upstream
> responsibility. Once upstream would be ready to move forward they could.
> Now either upstream is ahead of Fedora or Fedora is ahead of upstream of
> the application. We are rarely lucky that we would be in sync.


Yes, I got the reason why multiple version of a package are needed. But
that does not require them having the same name.


> There is even little motivation to do some continuous updates of Rails
> in Rawhide, since where is the point? It would just become moving
> target. While if I could keep behind each version packaged, it would
> make sense and find its users definitively.

There is a slight difference here to what was originally proposed. I had
assumed the people involved got this subtle difference but I am not
sure. So I repeat it here:

There are two (from my POV) very different way how this could work:

1. As described in the thread. There are separate branches that only
have one newest and supported package. This can be done with either
separate package names or some added magic that basically make the
packages behave as if they had different names. This magic requires
altering the packages. So you cannot just use the old packages. You
either rename them or add the magic to tell them their new update behaviour.

2. You just keep all versions of the packages of one single line of
updates and teach the depsolver (yum, dnf, rpm cli or whatever) to deal
with that in a way you like. People opting for an old package do not
receive updates (or are responsible themselves to choose a newer package
either by hand or by telling the depsolver which ones to consider.) This
way the package maintainer is not responsible to update any but the
newest version and does not even have to know about you using old
versions. If you have a repository that keeps the packages this should
be doable with a bit of yum magic even right now.

Florian