[distri] Re: Questions about packages and versioning

  • From: Michael Stapelberg <michael+distri@xxxxxxxxxxxxx>
  • To: Wiktor Kwapisiewicz <wiktor@xxxxxxxxxxxx>
  • Date: Sat, 19 Oct 2019 08:42:42 +0200

On Fri, Oct 18, 2019 at 10:27 PM Wiktor Kwapisiewicz <wiktor@xxxxxxxxxxxx>
wrote:

Hi Michael,

On 16.10.2019 23:06, Michael Stapelberg wrote:
It’s not entirely clear to me whether you’re suggesting that packages
should always be fully-qualified (like they are in Go) or only
optionally.

Actually both Go and Docker accept short names for either standard
library (in case of Go something like: import "io", or in case of Docker
anything that doesn't contain domain name is defaulted to Docker Hub).


The Go package name "io" is actually fully qualified, and not short for
anything. The standard library just lives at the root of the namespace, so
to say :)

You’re right about Docker, though.



Currently, my philosophy favors a centralized package repository where
software can be tested and bugfixed together, eventually converging on a
stable artifact such as distri’s current “jackherer” release branch. It
is much harder to get to a stable system when users are mixing and
matching software versions from different package repositories.

That's a good idea although in some distros I had more luck using
software vendor's repository than what was packaged in the distro (for
non-core software, i.e. Nginx).


There’s an exception to every rule :). I also run a few pieces of
vendor-supplied software directly, such as nginx via their docker container.



The "software can be tested and bugfixed together" seems to me like
something similar to what Clear Linux uses:
https://docs.01.org/clearlinux/latest/guides/clear/swupd.html#versioning

We in fact do the same thing in distri, though it isn’t as clear as it
could be, because it was added relatively late in the project: version
numbers are segmented in <upstream>-<revision>, where <revision> is a
monotonically increasing integer, just like versionCode in Android. We
should split this one field into two separate fields eventually.

Thanks for the explanation. I've seen "-revision" but the low numbers
made me think it's kind of a post-version number to indicate increasing
packaging versions (sometimes one version is packaged several times due
to adjustments).


That’s understandable—the revision number was just introduced pretty late :)



As far as I've seen there is no GPG or other signature verification both
on package and repository level. Is this planned or do you have some
other ideas in mind? (Just curious about the eventual security model of
these given some interesting advancements in Go:
https://proxy.golang.org/ ;).


Currently, we just rely on a trusted link to the repository: the repository
is only ever accessed via TLS, so as long as you trust that, you should be
good.

I’m willing to accept contributions which add certificate pinning for
people who don’t trust the CA ecosystem, but that’s probably pretty tedious
with today’s fast-rotating certificates.

I don’t have any big plans for signatures or other mechanisms. For what I
wanted to demonstrate, the current model suffices.

I do agree that the Go ecosystem is interesting here. For other readers not
familiar with it, https://blog.golang.org/module-mirror-launch might be a
good introduction post.



Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

Other related posts:

  1. Home
  2. distri
  3. Archive
  4. 10-2019