package, package2, package3 naming-with-version exploit

[Vít Ondruch]

Dne 3.4.2013 18:11, Florian Festi napsal(a):
> 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.

I am not asking RPM developers to change policy, I am asking RPM 
developers to lay out foundation. It does not make sense to change 
policy, if there are no tools to fulfill it.

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

Fedora mandates (and I agree) that packages should use unversioned 
dependencies, so there is a chance that you'll have to fix everything. 
But I agree that bit of virtual provides can ease the situation.

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

Well, if somebody wants to maintain some package, it probably doesn't 
matter which version. If somebody is qualified enough to maintain 
version X-1, (s)he is probably qualified enough to maintain version X.

>
>
> You somehow assume that just because we add some magic in rpm things in
> Fedora change dramatically.

No, that is not true ... I expect that even if you add the magic into 
RPM, I will need to fight again to change Fedora :)

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

Probably. But as you can see, I am not in favor of this.

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

I am leaving intentionally the "much easier" out of equation. "Much 
easier" means just "much easier", not "correct" or "right".

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

You are right, the number of packages will be even higher, because I 
would be motivated to update my packages more often, instead of fixing 
their API incompatibilities, which is task for upstream.

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

Ok, so what is the purpose of version field than? Lets drop it, if 
nobody cares. You could remove a few lines in Fedora, depsolver could be 
dumber.

Yes, I am exaggerating here, but does it make sense to have package 
python3-3.3? Why we don't have python3-1.0? Where is the version 1.0 of 
python 3? Why we duplicating the version? Non of these question makes 
you think that we are doing something wrong? Actually we are again at 
the beginning, since this is how the thread started.

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

I am sure that we could find a way how to work with packages, which 
would stick with single branch.

To be honest, this should be still the preferred way and seems to be 
subset of "multibranch scenario", where we have exactly one branch.

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

Yes, this is "install only packages" variation and this is the most 
basic scenario I'd love to see in Fedora.

Extension of this is that you should be able to update installed package 
of specific version, if its new release is available. That would allow 
to fix security issues in older packages.


Vít