package, package2, package3 naming-with-version exploit
Vít Ondruch
vondruch at redhat.com
Wed Apr 3 15:02:16 UTC 2013
Dne 3.4.2013 15:59, Miloslav Trmač napsal(a):
> On Wed, Apr 3, 2013 at 3:22 PM, Vít Ondruch <vondruch at redhat.com
> <mailto:vondruch at redhat.com>> wrote:
>
> Lets suppose we are in F14 timeframe and 2.3 are the newest Rails
> available and lets say we have in Fedora several Rails
> applications using Rails 2.3 API. They work just perfect to suit
> needs of their users.
>
> Now, in F15 timeframe, Rails 3.0 were introduced. So we would like
> to move the packages to Rails 3.0. But what to do with the old
> applications? How to provide support for them? Note that even at
> this point, although Rails 2.3 are not actively developed, they
> are supported by upstream, so no need for upstreams to migrate
> your application.
>
> 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.
>
> 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.
>
>
> OK, let's skip the re-reviews. That's obviously added work.
>
>
> ... and now, can we be specific? No handwaving, how would parallel
> installation _actually_ benefit you? How would the new system look
> like and work?
>
> Now, there comes security fix for Rails. Typically it impacts
> every stable Rails branch, i.e. it should be applied to two
> packages. 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.
>
>
> I can't see that parallel installation would help. Because there would
> be one git repo for all versions? That's orthogonal to having parallel
> installation of RPMs.
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.
Actually there were attempts to reintroduce rails23 into Fedora, but
they failed, since the maintainer was not dedicated enough. And why he
should be, since there was nothing wrong with the previous packages.
Current Rails are maintained, I don't consider to be big headache to
maintain more branches, but it gets complicated to maintain multiple
components.
> 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 can't see that parallel installation would help. We need to create
> and maintain as many packages as users require in either case.
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.
If somebody would developing for Fedora (that is very rare
unfortunately), (s)he could develop on whatever version of framework
which suits his needs. You could decouple development from package
updates, i.e. you would have stable development platform. More
importantly each Fedora has different version of Rails, so how, as a
upstream application maintainer, you can support multiple versions of
Fedora?
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.
I could be sure that update of the package does not break existing
application that are even not in Fedoras repositories.
And even security fixes may break things [1], so various upstreams
carefully consider updates of their underlying framework.
Vít
[1] https://github.com/rails/rails/issues/8832
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130403/bf297fce/attachment.html>
More information about the devel
mailing list