package, package2, package3 naming-with-version exploit

[James Antill]

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.

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

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

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

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

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