package, package2, package3 naming-with-version exploit

[Vít Ondruch]

Dne 4.4.2013 06:47, James Antill napsal(a):
> On Wed, 2013-04-03 at 15:22 +0200, Vít Ondruch wrote:
>
>> Ok, if we don't want to break anything, we have two options
>> 1) Just introduce new package rails30 and new applications can depend on it
>> 2) Move the rails package to Rails 3.0 and reintroduce rails23
>> compatibility package
>>
>> 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.
>   There is no way around this, you are introducing more packages (either
> by having a different name or by hiding them reusing an established
> name). There needs to be a process for this, if you are complaining
> about the "re-review" process when introducing extra "compatibility
> packages" like this, that has nothing to do with hiding two packages
> within a single name.

I am complaining about more things:

1) re-review
2) separate repositories
3) differently named spec, no matter if they are in single or multiple 
repositories

>
>> 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.
>   If you have one thing and then gain a similar thing, it's always two
> things (double). Doesn't matter if you give both of the things the same
> name just to confuse everyone, you still have two things.
>   This is important, and you keep missing the point. One plus one is two.
> Assume you have two apples, a red one and a green one. They are both
> apples, you can argue that calling them apple-red and apple-green is
> "bad" and that it should be apple/red and apple/green ... but you can't
> just call them apple everywhere and expect everything to magically know
> if it's the green or red one.

This is not the best example. Since I cannot reply to you that: "if you 
learn how to eat apple, you can eat also other apples". So speaking 
mainly about security fixes, they typically do not differ that much from 
one package version to other. I can always cherry pick the modification 
from one branch to other, while if there are two packages, I cannot. See 
the points above.

Actually if I leave the older version of packages behind me, there is 
not too much to worry about, since the churn in older package is usually 
lower then in the new one.

>
>   The user needs a way to refer to just one of the two, the other
> packagers need a way to refer to one of the two, all of our tools need a
> way to refer to one of the two, all of the developers need a way to
> refer to one of the two, and FESCO/FPC/etc. need a way to refer to one
> of the two.
>
>>   We even fix all the application
>> dependencies from rubygem-rails to rubygem-rails23.
>   Again this needs to be done even if you call the two things
> rubygem-rails, because you now have two versions of that name and all
> the pacakges depending on "rubygem-rails" need to distinguish between
> which version of the two things called that (or possibly saying either,
> but likely not).

This is already done by upstream, I don't care.

>
>>   We might try to
>> migrate some applications to Rails 3.0 and propose patches to upstream,
>> but considering this, it is already too much work.
>   The amount of work doesn't go down by confusing everyone and calling
> two things the same thing.

While you confusing users and you call the same thing, although a bit 
evolved different name. It is like if you would have different name in 
different age. Although you can reference James in his 15 years and 50 
years.

>
>> Now, there comes security fix for Rails. Typically it impacts every
>> stable Rails branch, i.e. it should be applied to two packages.
>   Ok.
>
>>   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.
>   You will always be working with two package/repositories ... because
> they are different things.

No, they are not. They are not that different. If I am applying patches 
to rails in different versions of Fedora, it is definitely simpler to do 
in one package in multiple branches then it would be done in different 
packages/repositories.

And I know that. Since I maintain rails in Fedora and I maintain rails 
in software collection. I can assure you that cherry-picks in Fedora's 
branches is different story then patching the software collection later 
(btw software collection luckily keeps the .spec file name, so one pain 
less at least).

>
>> 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.
>   Yes, in theory, someone could update rails23 to actually be
> rails23-3.1 ... don't do that.

:))

>
>>   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.
>   This is why random packagers aren't (and won't be) allowed to create
> new packages, or new versioned branches for packages. Otherwise the
> easiest thing to do causes a giant explosion of semi-unmaintained
> versions.
>

Everybody in Fedora is "random" packager in this sense. And I see it 
every day. I somebody wants to achieve its goal, (s)he'll do it the last 
painful way, not the correct way. You can educate people, but you cannot 
prevent everything. Especially if you do exception from simple rule, 
such as from simple "the name should match the upstream tarball or 
project name" you do "it is sometimes advantageous to keep multiple 
versions of a package in Fedora to be installed simultaneously. When 
doing so, the package name should reflect this fact ..."

I want to remove such exception.


Vít