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
- Just introduce new package rails30 and new applications can depend on it
- 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