Yes, PPAs. That's the closest you can get right now. If you don't think they're equivalent enough for you, then the answer right now is simply "no". Some comments on your claimed differences:
PPAs have compiled packages, while the AUR features both compiled packages and source packages
PPAs ship source packages too. PPA uploads must be source uploads. Users can access both the source (for example they can rebuild the sources themselves), or binaries built from those sources.
Since PPAs are specific to the Ubuntu release, many PPAs are out of date.
This is true. However, users can quite easily copy a package from any PPA to their own PPAs, including to a different release, while choosing to rebuild them if necessary on the way. See the Package details -> Copy packages page. If there is anything that needs updating to work with a newer release then that won't work, but I presume that's the same with AUR.
In terms of PPAs being up to date, that is presumably simply a matter of volunteer time (who can do the same pocket copy as above), rather than any fundamental difference between PPAs and AUR.
Many PPAs don't build properly, even though the projects are more or less stable
Same answer as above. This has nothing to do with infrastructure or mechanism and everything to do with volunteer time.
PPAs don't seem have a rating system where users can vouch for working package repositories.
Agreed.
There are tons of AUR packages that come directly from GitHub, so installing a package like something-git will usually give you the latest package straight from GitHub.
You could arrange for this to happen automatically in a PPA, but I admit it is far from trivial to set up.
- Arrange for an automated VCS import from Github.
- Create a build recipe.
None of this is exactly the same, I'll grant you. If you want more ABS/AUR -like functionality in Ubuntu, I think you need to go into more detail of how exactly your proposed changes would work in terms of what Ubuntu already has.
Unless you have the specific package version's .deb
file downloaded, you can only get what's available in the Ubuntu Repositories (or third party repos or PPAs configured on your system), and usually they only keep the Latest Copy of the package available in the Ubuntu repository itself at any given time.
This is the rmadison
output for rdiff-backup
in all current releases:
$ rmadison -u ubuntu rdiff-backup
rdiff-backup | 1.2.8-7 | precise/universe | source, amd64, armel, armhf, i386, powerpc
rdiff-backup | 1.2.8-7 | trusty/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
rdiff-backup | 1.2.8-7 | xenial/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
rdiff-backup | 1.2.8-7 | bionic/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x
rdiff-backup | 2.0.0-1 | focal/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
rdiff-backup | 2.0.5-1 | groovy/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
Therefore, if you are using any release before 20.04, you are stuck with either Nothing (because EOL) or 1.2.8-7. Any release after and including 20.04, you're stuck with 2.0.0 or later.
If you want another version, you'll have to go digging elsewhere because older versions would be ancient, and any OLDER version than 1.2.8-7 (while you can go hunting to TRY and find the .deb
for it in older pages and such, or try and compile the older versions yourselves, both of which are nasty options because you're going into 'untrusted sources' to get older versions.
Unless you explicitly need the older versions than 1.2.8-7, you should stick with the version of the package in the repos for your specific release, and not try and install a specific other version - which apt
can't do if there are no other versions available in your repository sources for your codenamed release (Bionic for 18.04, Focal for 20.04, for example) (Oh, and there isn't another version available for any of the releases at this time per rmadison
, except for the ones it lists per-codename.).
Also, keep in mind that 1.2.8-7
is version 1.2.8 but with package level revisions. ALSO keep in mind that at the time of 1.2.8 it had not migrated to Python 3 support - as a result, 1.2.8 may not function on newer versions of Ubuntu because of Python 2 package deprecation and drops in Debian which trickled down to Ubuntu 20.04 and later.
Best Answer
Packages are versioned in a pattern like
<upstream version>-<debian revision>
. In this case, the upstream version is2011.2~bzr663
& the debian revision is0ubuntu1
.Normally in Debian, the revisions are just numbers such, but for Ubuntu, the ubuntu1 following the revision indicates that there are source changes to that Debian revision.
0ubuntu1
is a special case, as it's used as a revision that indicates that it's not based on any Debian package of that upstream version (since there wouldn't be a debian revision0
).This is common when the Ubuntu package has been upgraded to a new upstream version ahead of Debian.