Re: Package naming when no backward compatibility at all?

[Greg Troxel <gdt%lexort.com@localhost>]

"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:

> I'm looking into creating pkgsrc packages for software that explicitly
> does not follow Semantic Versioning and does not promise API nor ABI
> backward compatibility even for a patch-level version change.  There
> could be other packages in the same software ecosystem that depend on
> this package or other packages with the same policy.  (Unfortunately,
> many do not say what their policy is.)  What's the best way to handle
> packaging the packages in such an ecosystem?

1) Do it in wip, and only if this proves to be other than a train wreck,
consider pkgsrc proper.  Include a comment in the Makefile that upstream
does not do Adult Software Engineering (ASE).

> Since one strategy in pkgsrc seems to be to put the version in the
> package name (e.g., lang/python27, lang/python313, security/gnupg, and
> security/gnupg2), I initially thought that I could do the same, but then
> I realized that since a backward incompatible change could be made for
> any version change, even a patch-level version change, I think I'd have
> to put the entire version in the package name (e.g., for foo version
> 7.0.8.1, I'd have foo7081).  But then I'd have a bunch of versioned
> packages.  Maybe that's the best I could do, but I'm not sure, which is
> why I'm asking.

I don't follow this.  In the general case, we have one package for one
upstream, name it without version numbers, and update it as releases
come out.

As a workaround for upstreams that don't do a good enough job of API
backwards compatibility, we package multiple versions with major
versions in the name, so that depending packages can depend on them.

Here, it's really hard to know how it's going to go.   Given that there
are a bunch of related packages, it seems likely that when one package
has an API break, then there will be new versions available of things
that depend on them.  Thus, there's no need to keep multiple versions.

Also, having multiple versions is clutter and messy, and for pythonXY,
that's ok because of the broad benefit.  I would be opposed to having a
dozen versions of 5 programs in pkgsrc becuase upstream makes
unreasonable choices.  I would probably even be opposed to that in wip.

> Maybe another approach would be to include the <major> or <major><minor>
> part of the version in the package name, but then declare a specific
> version of that package in all packages that depend on it.  I'm not sure
> this would even be possible, I'd have to study more, but I thought I'd
> ask before spending too much time investigating this approach if it's
> doomed to fail, or if there's a much saner approach that someone else
> might suggest.

Just package each one, with no versions in the name, and see how it
goes.  If updating something breaks everything else, wait a bit.  Ask
upstream how to deal.  Look at Debian, and other packaging systems to
see what they are doing.

> Yet another approach could be to package all the software in the
> ecosystem together in one pkgsrc package.  I'm not a big fan, but it
> would solve the dependency difficulty, I think, because then there'd be
> no dependencies between packages from the same ecosystem since they'd
> all be bundled into one monolithic package.

Icky for the package but not problematic as to what it imposes on
pkgsrc.

But really: pkgsrc is not special here, and the big question is what the
rest of the world is doing.

Also:

  "does not promise not to change the API" is different from "the API is
  broken often enough that this is a real problem in practice".  Make sure
  you are solving a real problem, not engaging in massive amounts of work
  to solve a theortical problem.   (To me, that's what it feels like you
  are doing.)

  If packages from this ecosystem are broken from time to time because
  of upstream ASE failure, IMHO that's ok.

  Think about a strategy of deferring updates unless the whole system
  builds (make a meta-package if there isn't one top package).  This
  will result in doing updates top-down, and that's ok.  It will be far
  less work than multi-version contortions.