Project

General

Profile

Freedom Issue #1755

[asp] Links to Arch source repositories instead of Parabola ones

nRoof - over 3 years ago - . Updated 15 days ago.

Status:
confirmed
Priority:
freedom issue
Assignee:
-
% Done:

0%


Description

Source code contains URLs to Arch Linux source repositories, so it works with sources of Arch packages not Parabola.

Steps to reproduce:
1. pacman -S asp.
2. asp checkout doublecmd-qt5 (or any other package name from libre which replaces the Arch package).
3. Verify the output.

Expected results:
asp package is either removed from Parabola or replaced by the appropriate package in libre that uses Parabola source repos, and so outputs from those. libre replacement should probably be renamed to psp or something like that, because I guess "a" in asp stands for Arch (not 100% sure about that).

Actual results:
Prints the address of Arch source repository to stdout and also checks out the sources of the package from that repository.


Files

psp.sh (2.88 KB) psp.sh A, 2021-10-17 11:05 PM

History

#1

Updated by bill-auger over 2 years ago

  • Status changed from open to confirmed
#2

Updated by A about 1 month ago

I started looking into adding Parabola's sources to what asp pulls from, but it seems to fundamentally build on packages having individual branches, which is not the case for Parabola.
Would adding branches for each package be viable to be able to extend asp?

I wrote a small script (attached) that works on Parabola's format, and also on Arch's by theirs also having package directories in the master branches.
The drawback of this approach is that you can't (as far as I know) fetch just one package directory, so instead it makes a shallow clone of each git repository and simply symlinks the requested package directory out.
This means we miss out on history, and the disk usage adds up since it can't fetch individual packages (257M for Arch's shallow community repository)
I'm also not sure if Arch's package directories in the master branches are up to date with the per-package branches.

#3

Updated by bill-auger 15 days ago

this is definitely a contribution worthy task for the long-term - it is part of the grander "TPPM" problem (#1035) - something should be done about all of them - compared to foreign TPPMs 'asp' is relatively native - so as a TPPM sub-task, 'asp' is a relatively easy one to tackle (eg: `pacman -Ssq` produces an adequate libre-filter for the arch asp repo directory names)

for 'asp' as a TPPM:
  • we always have the current complete/accurate package DB (in readily hackable forms)
  • we already know the libre status of each package in the DB
  • we already/routinely run the same filters on the arch binaries
  • the infrastructure payload/system-load is negligible and maintenance could be easily automated

just equal parts of clever planning and shell scripting - the same code could instead/also be/become a new feature of libretools

there are multiple solutions which would obviate 'asp' entirely (ie: close that ticket by blacklisting 'asp', with no loss of functionality to parabola users) - i imagined one solution, that `mkdir -p core/foo && cd core/foo && libremakepkg` could download a PKGBUILD set ("on-demand"), based on it's dirname - curl could get them from parabola's cgit, removing the large VCS burden from users

FWIW, liberating 'asp' is equivalent to a similar plan for the 'octopi' program, to restore it's AUR-helper features - AUR-helpers serve much the same purpose as asp; and i suspect that more people prefer AUR-helpers to asp - an AUR-helper is probably the most popular feature expected by arch/manjaro users, yet missing from parabola - the 'octopi' plan may be on a ticket - it is fundamentally the same job as this, plus some python? GUI work - we should consider linking several of these tickets

Also available in: Atom PDF