Why is the Tixati package removed?

Help
1

I tried to install Tixati, but got this message:

error: 'tixati' has been removed from nixpkgs as it is unfree and unmaintained

It is both free and actively maintained.

In 2024 it has gotten six version updates and on their website it says it is:

100% Free, Simple and Easy to (blabla)

Was it removed by mistake somehow?

2

The removal does not provide any more information.

But unfree typically refers to license, not price.

And by unmaintained, they probably meant downstream (in Nixpkgs) – the package had no maintainers at the time:

3

really seems like it shouldn’t have been removed from the immediate information provided in this thread - maybe we’re missing some facts

@wegank any additional information you can provide?

4

I just copied the message from tixati: 2.89 -> 3.16 by r-ryantm · Pull Request #193815 · NixOS/nixpkgs · GitHub when dropping the package, and if the message is not true, we should absolutely fix it.

I don’t think there’s anything preventing us from reintroducing tixati either, if someone wants to do the reinit at a recent version and become the maintainer.

5

we have plenty of unmaintained packages in nixpkgs but with our automated infra it isn’t a problem and we really shouldn’t be removing them unless they become a problem

6

Edit: This was in response to jtojnar. The other responses appeared while I was writing this :smiley:

Aha, thanks! Yeah, after checking again it turns out the license is proprietary.

Can I ask about the unmaintained part - does “downstream” mean that a person associated with NixOS in some way was responsible for updating the package version? And not the developer? A Nix-person was responsible for retrieving the package from the developer and putting it in the Nix-repos or something? Is this the same for ALL NixOS packages? And maybe in all linux distros?

7

“Downstream” means nixpkgs; no one cared enough to look at it in over 2 years.

As wegank said above, if someone wants to maintain the package in nixpkgs they’re welcome to reintroduce it.

1 Like
8

I still stand by my comment in the r-ryantm PR. Nobody maintained it (by providing comments to r-ryantm updates about whether it’s working). Generally it’d be nice to keep everything forever, but with auto-updates (and toolchain updates) there’s no guarantee things keep working. I much prefer people reintroduce packages when they’re really interested to keep nixpkgs maintainable. When such packages break there’s often nobody picking up the trash if there’s no maintainer.

There’s always the option of using an old nixpkgs version to use an old package, and with enough interest the package will be reintroduced at some point. Otherwise it’s likely a good riddance.

3 Likes
9

Yes, yes and yes! Linux distros are projects by a bunch of people who take whatever other projects they’re interested in, (optionally) build them so you have binary versions that you can download without having to figure out how to build them yourself, and then integrate them to ensure their dependencies match up with all the other projects a Linux distro packages and don’t cause conflicts. Then configuration is added to make the whole set of things a distro is composed of into a bootable Linux system. It’s an odd type of meta-software-project that became necessary when software inter-dependency exploded.

Usually “downstream” refers to the direction of dependency between two projects in a specific context. A Linux distro always depends on all their input projects, e.g. in this case NixOS is “downstream” of tixati, while tixati would be referred to as “upstream”. Your NixOS config on the other hand is “downstream” of NixOS. Tixati could very well also be both “upstream” and “downstream” of NixOS, if their developers used nix to build it - you’d change the word referring to it based on what role each project takes in the current conversation.

Maintaining a package means doing all the work to ensure a project works on a distro (particularly hard for NixOS because it lacks fhs compliance, doubly so for proprietary packages) and that updates make it into the package repo while maintaining backwards compatibility within a release cycle, or otherwise preventing users from being affected by problems caused by updates.

If a package is not maintained, you run the risk of security updates not being applied, causing lots of users to be vulnerable, so packages should probably be pulled if they’re no longer properly updated (and there is not sufficient trust in automation to pick up the slack). What “properly” means is up to distro policy - a detail which this thread will probably discuss shortly :wink:

1 Like
10

there is no guarantee they will break

sure but now we’ve broken nixos for users of this package for no real reason

your talking points make perfect sense to me once we get to the point of breakage - if a package breaks and no one is maintaining it then removing it is the reasonable action… but up until that point i don’t understand why we are removing

11

Because it was a year out of date at the time. We need someone to functionally test the binary and ensure it works, if no one’s willing to do that then keeping a bitrotten and outdated package around does us no good.

We probably don’t remove enough packages honestly.

2 Likes
12

agree to disagree i guess :man_shrugging:

13

Let me put it this way - I’ve spent enough time in some unofficial spaces where people just complain that such-and-such is unmaintained/outdated, but many times, rather than filing a GH issue, they just don’t use the package and try to find a flatpak or something. (Or sometimes quit using nix entirely.) I would rather not continue to give the impression that we are maintaining something (by its inclusion in nixpkgs) and yet not actually maintain the thing.

There is a breakage when you leave packages out of date for years. What you don’t see is the end-user breakage (even if the package nominally “builds” fine), if you don’t use the package. Especially for proprietary packages where there is no actual building occuring, just extracting some package - which would probably never fail at buildtime, but can easily fail at runtime as libraries update or online-connected services change their APIs. Even now, I don’t see anyone volunteering to maintain it, so it may continue to be not-included in nixpkgs.

1 Like