[distri] Re: Questions about packages and versioning
- From: "Wiktor Kwapisiewicz" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "wiktor" for DMARC)
- To: Michael Stapelberg <michael+distri@xxxxxxxxxxxxx>
- Date: Fri, 18 Oct 2019 22:26:57 +0200
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).
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).
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).
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/ ).
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
Other related posts:
