Why is Fedora's 'android-tools' package so old?

The android-tools package version is from 2018 (20180828gitc7815d675), two years old. android-tools | Package Info | koji
That’s surprising to me for a distro that stays very up to date.

In contrast, there are regular and recent updates from the Android SDK Platform Tools: SDK Platform Tools release notes  |  Android Studio  |  Android Developers

I prefer installing from the repos, but why is the package so old, especially in an area of such active development?

1 Like

Judging from the commit activity, the packager might be inactive but hasn’t orphaned the package. Interestingly, nobody seems to have filed a bug requesting an update yet, so you could probably do that first - maybe there is some reason we don’t know about.

1 Like

We are run by volunteers is what I would want to answer. :stuck_out_tongue:

Judging from the Koji channels, it is quite difficult to find a packager who stays put.

2 Likes

Aside from it being off-topic, I don’t buy this commonly repeated excuse:

  • Up-to-date distros are not necessarily paid
  • OSes with paid staff are not necessarily better managed

What exactly is the point of this comment, other than trying to deflect some blame?

IMO it is an organizational issue.

Stale packages and inactive maintainers should probably be automatically flagged for attention if they aren’t already.

In any case, a bug has been filed: 1873878 – Fedora package outdated vs upstream

1 Like

Yep. There are paid contributors, true. But the vast majority of package maintainers are volunteers.
And yes, inactive maintainers are often flagged if necessary. And the packages maintained by them will be orphaned: the package will be evicted from the distribution if nobody step up to take the maintenance of their packages (on a voluntary basis in the vast majority of the cases, as said before).

3 Likes

Once again, there are both non-volunteer and volunteer organizations that are well-managed, and instances of both that are not. Mentioning that maintainers are volunteers is irrelevant to the state of the organization.

The implication of this argument is a 1:1 correlation between pay and results, which is especially peculiar coming from linux users.


Luckily, this maintainer is responsive. The issue is with the android build system being unavailable in Fedora. Thus, packaging relies on custom build scripts, which is the reason it is not updated frequently. The maintainer hopes it will happen soon™.

Sorry but are we talking about the state of an organization or the state of a single package?

I disagree. When I say that a specific task is accomplished by volunteer people is a way to suggest that we should be tankful to this people and that such people deserve our respect and understanding [*]. Stating that a task is performed by voluntary people is not a way to suggest that paid people do a better work.

[*] You know: ranting, complaining and criticizing is a pretty easy exercise when you are not the one involved in a task.

4 Likes

That is probably true whether or not those who accomplish the task are volunteers or paid. So yet again, it is an irrelevant factor that is brought up to justify when there is a lapse.

As it turns out, the maintainer of android-tools has not abandoned it, and has promptly provided technical reasons why the package is so old.

Come on. It is a fact that most maintainers at Fedora are indeed volunteers, contributing and packaging just for the love of this polished roller and for their will to help. We can hope for things to stay up-to date but we can’t quite expect that right?

Just compare that with AUR where you have things bleedingly up-to-date and see how unpolished things might be when there is a lack in finesse. There should be an understanding that a volunteer is not obliged to the cause and an absence is okay :sweat_smile:

1 Like

Good to know. Custom/complicated build systems are often a problem for Fedora packages, as Fedora doesn’t ship anything that is not build from source. Actually, I shouldn’t have assumed the maintainer to be absent, given that there were no unanswered bugs against the package.

Such procedures exist.

  • Most packages are mapped to upstream projects using https://release-monitoring.org/, that system automatically files bugs against the package when upstream releases a new version (not just for Fedora, by the way).
  • For maintainers who do not respond to bugs or contact attempts, there is a policy for unresponsive maintainers that allows their packages to be orphaned/taken over by others.
  • All packages that are orphaned are posted to the devel mailing list at regular intervals, packages that have not been taken up after 6 weeks are automatically removed from the distribution.
  • Packages are automatically rebuild when their dependencies change, and if those builds fail, a bug is also filed automatically.

Now, obviously there are caveats with this. For example, the automatic release monitoring is (currently) not mandatory and maintainers can choose not to activate it (you can check this under “Monitoring status” on each package’s page on src.fedoraproject.org/rpms/). Also, it obviously fails when the upstream project does not mark their releases in a computer-readable way.

Fedora - like most distros - has a huge package ecosystem, which is why we use automated systems like the ones described to catch problems like stale or non-functional/buggy packages. But things that aren’t caught automatically will not be fixed unless a) the (or a) maintainer notices or b) a user asks/complains.

Edit: The policies regarding unresponsive maintainers & orphaned packages have changed fairly recently, so there currently is still a bit of weeding out going on. Also, tighter integration with the automated system is an ongoing project.

6 Likes

Good, but as you mentioned the existing procedures leave something to be desired:

It’s not the first time encountering a stale package.

All is well that ends well. Nevertheless, one can aspire to improvements.

No and no.

I encourage those who think so to avoid confusing different variables together. Type of association (volunteer or employee), vs standard of results and responsibility (absence, work quality), vs organizational goals (polished stable product, bleeding-edge up-to-date releases, etc).

In my view, just because they are not paid, a volunteer does not have any less responsibility to meet their commitments than a paid employee. It is up to a given organization to set their standards and goals, and have procedures to enforce them. The type of association of members is irrelevant. If they cannot or no longer wish to meet the standards, they are of course free to dissociate.

Much like free software actually refers to different variables sharing the word “freedom” (free as in free speech vs free as in free beer) and should not be confused, joining an organization voluntarily does not mean that quality standards and being responsible are voluntary.

True. I’m seeing improvements, but there is of course room for more.

Jumping into the ‘volunteer’ debate for a moment, I think here is (one of the) underlying issues:

It’s totally OK for a maintainer to fall behind keeping something up-to-date for a while, because spare time is lacking or whatever - that’s the core difference between paid and volunteer work, the latter is all done with spare time. But sometimes, people will just silently stop maintaining their packages. That, and I fully agree with you here, volunteer or not, is not OK.

Among the active maintainers, you mostly have group A who happily maintain their few packages and do it well, but aren’t/can’t be/don’t want to be much more involved than that. They won’t notice that somebody has dropped off the grid. Then you have group B, who are very involved & maintain as much stuff as they can cope with. They won’t notice either, because they don’t have the time to go around randomly checking up on other packages.

The problem is that if you are in A, and want to donate more of your time to the project, then it’s likely you’ll end up in B, because there are A LOT of packages that need taking care of (just check the regular emails about orphaned packages …). So you’ll end up lacking people who have the time/desire to just generally poke around the repositories/bugzilla (Tbh, I don’t know if that is even feasible, given the number of packages in the repos). Automated systems help, but don’t catch everything.

For stuff that many people rely on, issues will get noticed rather quickly (nobody will overlook gcc getting stale). Same if the software starts failing to build. But packages that build & are simply outdated, that nothing else depends on and that aren’t widely used within the maintainer collective? Not so much.

This is where the community aspect comes in. We rely on users like you to fill in this gap for us, to let us know if something is wrong/outdated, here or by filing bugs.

4 Likes

Your sense of entitlement here is highly demotivating to me as a packager. I don’t have a responsibility to you or anyone else for the packages I maintain. I do my best to keep those packages up to date, but when I fall behind I don’t lose sleep over it. Maintaining the package collection is a team effort. Have you sent a pull request to update that package? Have you asked to be added as a co-maintainer of the package so you can help keep it up to date? It makes me sad that we can never find enough packagers, but there is no shortage of users demanding answers for “why is this package out of date?”.

6 Likes