package, package2, package3 naming-with-version exploit

Thu Mar 28 16:47:52 UTC 2013

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130328/1244689f/attachment.sig>