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