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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
