One disclaimer to start off -- We're on a big tangent here. If I understood the original poster correctly, he'd concerned about what we name parallel installable versions of packages rather than whether we should have parallel installable packages at all. That said, there's a lot to say about parallel installable packages so I'll jump in here. On Thu, Mar 28, 2013 at 08:31:22AM -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/28/2013 08:30 AM, Jan Zelený wrote: > > On 28. 3. 2013 at 12:59:44, Vít Ondruch wrote: > >> Dne 28.3.2013 12:09, Florian Festi napsal(a): > >>> This is done to make life easier for package maintainers. > >> > >> Sorry, you definitely not speak for me! This are just excuses. > >> And I asked already several times to have some way to reliable > >> support multiple version of packages without mangling their > >> names. > > > > Víťo, I certainly understand your frustration, as it comes from > > talking about this topic over and over again. However Ruby > > community is a *very* special case in this regard and I'd like to > > treat it as such. > > > > If you want, we can start a discussion here. But if we do, let's > > keep the discussion strictly constructive and just about > > *technical* problems. Let's not take this to design level of > > things, as Ruby and Fedora are two completely different worlds that > > will never be fully compatible by design. Therefore the final > > solution (if there is any) has to be some sort of compromise. > > > > It's not just Ruby that has these issues, though. To take a python > example: Django. Most Django packages are built against a specific > minor version of Django, and the Django upstream regularly breaks > backwards compatibility with those minor releases. > > It ends up requiring Fedora to carry multiple copies of python-django > in the repo, usually versioning the older ones (so in the current > situation, we have python-django and python-django14, with > python-django referring to Django 1.5) Note: Is this a hypothetical? I'm unable to find a python-django14 (or other versioned python-django) package build in koji. PyCon was nice this year as I got to talk with Nick (who straddles the upstream/distribution divide) as well as a bunch of upstream and a separate bunch of downstream (Fedora/RHEL/Distribution end users) about this. After all of this, I've been thinking about who needs to do what work to achieve what ends. Who is involved: * A package maintainer * A distribution as a whole * A software developer (free software application) aka: upstream * A software developer (web services) * An end user (RHEL sysadmin) * An end user (new to linux) What motivates these entities: * Package maintainers want to get their particular package running on their favorite distribution. * The distribution wants to create a high quality, maintainable system that they would run and/or can advise other people to run. * The upstream wants more end users to use their software and make identifying bugs in their software as easy as possible. * A web service developer wants to have a stable base system with cherry-picked specific versions of anything they are actively working on. * Sysadmins want to get high quality software from a reliable vendor and then be able to leverage their existing knowledge for adapting that software to their specific needs. * new-to-linux end users want to run applications that help them do their specific tasks on a stable platform. These motivations are not completely without conflict so I don't think that we can have one-size fits all. What we can try and do is take care of our motivations while creating and promoting ways for other use cases to be met. Let's limit this particular email to package maintainers and distributions as they're what we deal with most. It might seem like package maintainers and distributions as a whole should be on the same page since the former is what makes the latter possible but this isn't always the case. Package maintainers have the capability to focus on a very specific portion of the distro (a few to a single package). Doing what's best for that package may not be what's best for the distribution as a whole. Pulling an example out of the distant past, once upon a time Zope was a large, well known web framework that happened to require python-2.4. Fedora had moved on to python-2.5. It was proposed that as the package maintainer knew how to package but not how to port zope to python-2.5+, the package maintainer would want to simply maintain an alternative python2.4 package and software stack. FESCo decided not to allow the parallel stack for a variety of reasons (bug reports would be filed against the main python stack but should be targeted at the backwards compatible stack, upstream python-2.4 support would be discontinued so we would have to shoulder the burden of fixing the package, we'd have to ship not just python2.4 but also python2.4 modules). FESCo judged that the proper way to support zope would be to port zope to run on python-2.5. In this case, the ruling of the distribution as a whole was that maintaining a backwards compatible stack wasn't maintainable for the distribution as a whole. Talking about web frameworks similar concerns exist. Carrying multiple copies of Django might be the easy way for a maintainer to get the web application into Fedora that they want. But doing so increases the overall maintenance requirements of the distribution by requiring not just the new django but also the addons that web applications running it might require. It might be better to front end load the work by helping applications to port their code to a newer version of the framework rather than waking up one morning to find you need to figure out how to backport a CVS from a newer version of Django to the old, unmaintained version that is only needed by your application. OTOH, there are potential differences as well. Perhaps the web framework in question says that they will maintain a specific older version for the time period that Fedora cares about. Perhaps the addons will work for either the older version or the newer version so we don't need to build a new stack of those -- it's only the applications that care. Perhaps a maintainer from the upstream web framework is willing to maintain the backwards compatible package. Things like this are the reason we don't have a single rule that disallows or allows backwards compat packages but instead deal with things on a case-by-case basis (mostly at a maintainer level, a few times escalated to fesco). I would say ideally a distribution would like all packages to be ported to a single newer version of their dependencies. Our maintainers would help upstreams to port to newer versions rather than simply demanding that upstream does the work for them. In our less ideal world the next best thing is backwards compat packages in specific cases where upstream is still maintaining the older version and our maintainers.re capable of helping to fix bugs in the packages. We work to port things forwards with upstream but we may not get things updated for every release. [Note: as promised, I only dealt with the distro and package maintainers here... There's a lot of room to explore how to best serve the other entities but that should probably be talked about in a different thread.] -Toshio
Attachment:
pgpHRV9PNFlcJ.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
