Replies: 1 comment 1 reply
-
|
Hello, thank you for reaching out to us and for packaging the Nix package, this will definitely help Immich to reach more users. After discussing with the team, below are our answers about the inquiries above
Further, you've prompted us to create a channel on our Discord servers for downstream package maintainers to have direct contact with the team. Feel free to join (https://discord.immich.app/) and ping an Admin for access. That'll give a convenient central place for all packaging discussions, though of course if you prefer to keep in touch through other methods that's fine too. Let us know if you have any questions. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
Wow that was quick, you guys really do move fast :D
Note that it was @jvanbruegge who ported Immich, I am merely someone with merge permissions who reviewed the PR (and of course an Immich user ;) ) I do plan on at least helping out in testing package and module changes though.
That's a good target, non-LTS distros should be able to keep up with that standard.
This is valuable information, thank you!
Please do, us distros generally don't desire upstreams to feel heavy friction in this regard.
Which option exactly? I highlighted a few examples of how it could be handled and discussed the option of no NixOS-specific branding.
Hm, discord isn't really a great medium for something like this, nor is it very popular among distro maintainers IME. Most of us folks at NixOS are on Matrix for instant-messaging purposes for instance. While I do still have an account, I basically never have discord open. From googling around, I gather that you also can't get email notifications for pings or messages in channels. I can't speak for the primary immich package maintainer though. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
As of yesterday, Immich has been packaged in Nixpkgs and a NixOS module has been created: NixOS/nixpkgs#324127. I am a Nixpkgs/NixOS maintainer and Immich user, so this is exciting to see.
What I wanted to discuss here is the relationship between the Immich project and us as a downstream distribution. Disconnect between distributions and upstream projects has caused issues in the past in many cases, so I want to pre-emptively avoid them.
Rather than the upstream-made and -sanctioned deployment scripts and artifacts, there is now a separate distribution and deployment of artifacts that works differently (in the case of NixOS even more differently than a typical distro would) and that some users are going to use instead.
Immich is quite a sizeable software project and also quite a fast moving one which presents a few unique challenges for us distro people that I'd like to discuss with you.
Compatibility with the rest of the ecosystem
As general-purpose Distros, our job is to integrate a set of software with another. Immich depends on a pile of other software that we must manage and integrate too. If there is even one piece missing or wrong in this pile, that would likely affect Immich too.
What us distros mostly need here is clear communication of breaking changes w.r.t. dependencies. These include requiring new versions of major dependencies such as i.e. pgvecto-rs.
It'd be great if you could mention updated requirements in the release notes so that we don't need to go hunting for such requirements and perhaps miss one, potentially causing issues. It'd also be great if you could be a little considerate of us when making choices w.r.t. using new dependencies or new versions thereof because distros generally can't ship new and/or update components quite as quickly as you can put them into a docker container ;)
Experimental packages or versions might not even be allowed in distributions until they become official.
Distros can find ways around this but if you have the option to not use the newfangled thing that's barely field-tested, it'd be great if you could keep us in mind in your decision.
Compatibility with the apps
I'd wager most people use Immich in combination with one of the smartphone apps.
As a distro, we will naturally lag behind upstream releases. Even in fast-moving distros you can typically expect an update to land on user systems no sooner than a few days~a week after the upstream release. Slower distros may even take a few weeks and it's often not predictable though much of it depends on changed dependency requirements.
The smartphone apps are distributed by the respective app stores and we must expect them to be auto-updating on users' phones quite soon after you release them.
Now naturally the question arises of whether the app remains compatible with an Immich server whose version might be a bit behind and by how much.
Can a newer app keep running with a server that's a few weeks behind? A few months?
Do you have a policy on this matter or experience with which you could make a prediction here?
It'd again be great to have breaking changes in this regard mentioned in the patch notes.
NixOS stable
We at NixOS have stable releases twice a year whose purpose is to mostly stay at the initial state for the entire 7 months maintenance period, making exceptions only for security patches, critical bugs or compatibility with outside systems not in our control (i.e. youtube-dl).
This circles back to the question of whether the Immich apps would work with a quite outdated version of Immich as stable can be expected to be up to 7 months out of date which is quite a lot more than the few weeks max. it'd typically take us to update.
We could justify backporting every update but it's not certain that we will always be able to do so as stable might (intentionally) not have the required dependency versions as to not break other components depending on the same dependency.
Nixpkgs is quite uniquely in a position where we could reasonably work around these issues as we can have infinitely many versions of the same component "installed" without interference but this problem still exists at a higher layer where it's easier to manage but it's still there. In short, it's not necessarily easy or feasible even if it's theoretically possible or easier.
Branding
Our packaging and our policies surrounding packaging Immich and its dependencies can introduce bugs that do not exist in regular Immich as packaged by you. We of course strive to avoid them but we're not perfect and these potential issues caused by us could reflect poorly upon the upstream Immich project.
To avoid this, we could make it clearer to users that our package (with potential issues caused by our code or policies) is not necessarily representative of the upstream intention.
Additionally just from a purely practical perspective, not only do we not want you to be notified of bugs caused by us, we want to see them in our issue trackers instead.
We could for instance clearly mark our version by e.g. adding a version suffix, labelling the package "immich-unofficial" or putting a "Nixpkgs version" in an obvious spot such as beneath the logo.
This would be a bit of effort, so we won't do this unless you explicitly ask us to. That is well within your rights though of course.
Speaking of which, technically the AGPL has some quite strict terms which requires us to explicitly state that we modified Immich but this is rarely "enforced" as upstreams often don't care about this detail; intending a GPL but for networked services. It'd be great to know what your stance is on this to be safe from a legal standpoint too.
Some projects even hold trademarks for this purpose. A good example here is Firefox which we're only allowed to distribute it under the "Firefox" name because we have explicit permission from Mozilla because a Mozilla employee considered our packaging to be of a high enough standard.
stateVersion
One more little thing is that we have the concept of a stateVersion in NixOS which defines which version of NixOS was used to create state on-disk. This is important for applications that are closely tied to their on-disk state such as i.e. postgresql. If you set up your system years ago, postgresql will have created its state using the then-newest version which is of course quite old by now. In order to continue using postgresql with this old on-disk state, NixOS automatically selects the matching old version as the default postgres version used.
If Immich has similar on-disk state that cannot be read by a future version, please mention it in that version's patch notes so that we can make such transitions as smooth as possible for our users.
Beta Was this translation helpful? Give feedback.
All reactions