Skip to main content
Topic: Adapt yaourt to honour Artix' repositories? (Read 666 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Adapt yaourt to honour Artix' repositories?

Dear Artix people,

you serve the package yaourt in the [galaxy] repository. This is convenient since it means automatic updates.

Would it be possible to adapt yaourt such that it is able to also download package sources from artix?

Currently, in
  usr/lib/yaourt/abs.sh,
in the function
  abs_get_pkgbuild(),
it is hardcoded to just look in Arch Linux' upstream:

If the package is from [core] or [extra] or [testing], it will download
  https://git.archlinux.org/svntogit/packages.git/snapshot/packages/$pkgbase.tar.gz,
otherwise it will download
  https://git.archlinux.org/svntogit/community.git/snapshot/community-packages/$pkgbase.tar.gz.

Would be good if you adapt it such that it also checks for Artix' repositories and generates the appropriate download URLs, and it would be even better if there would be a configuration file option where people can add arbitrary repository -> download-URL mappings in case people have other (unofficial) repositories enabled as well. Where the latter one is more a wish for the yaourt-developer, the first one seems to me to be a key thing if serving yaourt in the artix repositories.

Use cases for this for example:

  • Having a package customised with a customizepkg-hook and wanting to have it work smoothly also with other repositories than the Arch Linux ones (which is my use case, I use costomizepkg-scripting, and customie the build of for example ffmpeg, and yaourt fails on retrieving ffmpeg package sources),
  • Wanting to get the sources via yaourt -G to build oneself (coming back to the ffmpeg example: yaourt -G ffmpeg fails. ffmpeg is in [world]. ffmpeg -G extra/ffmpeg (forcing from Arch Linux' [extra] repository) works, but that will bring in Arch Linux' notion of ffmpeg, not Artix Linux' variant; and of course it fails on automated runs with e.g. customizepkg, and there won't be such a workaround if the package is not also present in the still-enabled Arch Linux repositories or the AUR).

Re: Adapt yaourt to honour Artix' repositories?

Reply #1
I can take a look, but for getting artix packages sources, its much easier to just clone the artix git repos.

Re: Adapt yaourt to honour Artix' repositories?

Reply #2
I can take a look
thanks,
Quote
but for getting artix packages sources, its much easier to just clone the artix git repos.

This costs traffix (a big issue for me), space, and will not work with automated customizepkg-honouring updates à la yaourt -Syu.



I also posted it to the yaourt-developer(s), that a configuration file entry to add arbitrary [repository] -> download URL(pattern) mappings is useful, but I don't think they will take care of it.

Maybe at some time I dig into it a bit, and patch abs.sh in place. (I already have a customizepkg-hook for yaourt that makes package build fail (instead of silently continuing) if customizepkg fails, and I posted the issue and patch to the devs many months ago, but nothing happend yet).

Re: Adapt yaourt to honour Artix' repositories?

Reply #3
Point being, you shouldn't be using yaourt to build packages.
Use makepkg.

Re: Adapt yaourt to honour Artix' repositories?

Reply #4
Point being, you shouldn't be using yaourt to build packages.
Use makepkg.
Why?

This involves checking manually each time if a package where a customizepkg-hook exists for has been updated, and manually do download sources, apply patches, and build. This somehow breaks the scope of customizepkg in my opinion.

(Btw., yaourt invoces makepkg. So, formally, makepkg is used anyway, but this does not seem to hit your point. So, why?)

Re: Adapt yaourt to honour Artix' repositories?

Reply #5
Frankly, yaourt is a convenience wrapper for people who have no real clue what they are doing.
The reason you should not use yaourt, you basically compile sourcecode in blind trust it won't do harm.
The AUR is not protected from people uploading packages that compile malware.


But I am slightly wondering, you say you have limited data transfer, but you run a rolling release distro? How come you can't clone a small git repo once, but you update your rolling release regularly?

Re: Adapt yaourt to honour Artix' repositories?

Reply #6
Frankly, yaourt is a convenience wrapper for people who have no real clue what they are doing.
The reason you should not use yaourt, you basically compile sourcecode in blind trust it won't do harm.
The AUR is not protected from people uploading packages that compile malware.
I know. I am aware of the risk.

makepkg does not protect from this either, unless you look at the source. (But who does, really?)

Looking at the PKGBUILD and install=-files is in turn easy with yaourt, too.

Giving that, what should me make trust the official repositories more? That there is not some malicious code put somewhere, more or less hidden, maybe directly in upstream?

.. well, and when I use yaourt just to get PKGBUILD and associated files from Arch Linux/ Artix upstream, and not from the AUR, I will not interact with the AUR at all.

And that was my use case. Packages which are provided in some repositories, and not in the AUR, where I have a customizepkg-hook for them, to be taken care of somehow automatically during an update, and then not fetching the precompiled binary from that repository but the source build recipe (PKGBUILD etc.) from _the same_ repository, not the AUR.

The only thing I will mostly miss then are the signatures.

Given the last sentence: PKGBUILD has also support for source file signatures, and for example extra/ffmpeg also supports it. From the PKGBUILD downloaded with yaourt -G extra/ffmpeg:
Code: [Select]
source=("https://ffmpeg.org/releases/ffmpeg-${pkgver}.tar.xz"{,.asc}
        'fs56089.patch')
validpgpkeys=('FCF986EA15E6E293A5644F10B4322F04D67658D8')

So, where do I have more security problems when I let yaourt download and build extra/ffmpeg compared to when I just download and install the prebuilt package with pacman -S extra/ffmpeg?

Given that, not all packages provide validpgpkeys, for example extra/kate (where I also have a customizepkg-hook for).

Quote
But I am slightly wondering, you say you have limited data transfer, but you run a rolling release distro?

System update only every now and then. A few weeks to a few months. When I have quick connection somewhere and the time to deal with it (since every update does potentially break something).

I have unlimited data, but usually on sth. like 40 kbit/s.

Individual packages without system update I install sometimes (knowing that it is strongly discouraged and might not work out).

Quote
How come you can't clone a small git repo once, but you update your rolling release regularly?

No one said that I update it regularly ;).

OK, I got it. I don't need to update the git repo more often than I need to make a system upgrade. Right.

And I mis-thought something there, because I was not relly thinking of it, just reacting affectionate: Thinking of having to clone all the sources of all the packages, which is much more data than the subset of packages I have installed on my system. But it is just the git repo containing the package's build recipes. Thanks for that last sentence from you, which corrected my thinking on that.

Patch -- Re: Adapt yaourt to honour Artix' repositories?

Reply #7
I finally made a patch for yaourt honouring the Artix repositories.

It is attached, and there: http://ix.io/Teq

As well as a patch which makes yaourt abort if customizepkg fails (attached, and there: http://ix.io/STN)

And the new PKGBUILD (attached, and there: http://ix.io/TeG), alongside with a patch for the old PKGBUILD (attached, and there: http://ix.io/Tf6; the patch is made suitable for use with customizepkg-scripting (patch made in a way to not incorporate Artix' sha256sums, so a change just there makes the patch not to fail to apply)).

Guide to the attached files:


Also note, by the way, that the file 0001-alpm-artix-brand.patch which is part of Artix' yaourt sources does miss a newline at the end (patch warns about that when applying your patch):
  patching file lib/alpm_stats.sh
  patch unexpectedly ends in middle of line
  Hunk #1 succeeded at 40 with fuzz 1.

Re: Adapt yaourt to honour Artix' repositories?

Reply #8
This is yaourt -Syy no patches what am I missing here as it works fine


:: Synchronising package databases...
 gremlins                  55.5 KiB  78.3K/s 00:01 [######################] 100%
 system                   175.7 KiB   116K/s 00:02 [######################] 100%
 world                    544.1 KiB  67.7K/s 00:08 [######################] 100%
 galaxy                    95.5 KiB  77.1K/s 00:01 [######################] 100%
 extra                   1598.3 KiB  85.3K/s 00:19 [######################] 100%
 community                  4.2 MiB   106K/s 00:41 [######################] 100%

Re: Adapt yaourt to honour Artix' repositories?

Reply #9
This is yaourt -Syy no patches what am I missing here as it works fine

The patched version builds from our github sources too, yay! Now we can funroll-loops while we funroll-loops!

Jokes aside, I like it because it would allow quick rebuilds of broken packages with mismatched libraries and save the day until the lazy Artix devs fix them upstream. May I suggest renaming it to yaourtix? Perhaps it could be included in [galaxy], when sufficiently tested.

Re: Adapt yaourt to honour Artix' repositories?

Reply #10
I finally made a patch for yaourt honouring the Artix repositories.

It is attached, and there: http://ix.io/SVb

As well as a patch which makes yaourt abort if customizepkg fails (attached, and there: http://ix.io/STN)

And the new PKGBUILD (attached, and there: http://ix.io/SVU) alongside with a patch for the old PKGBUILD (attached).

NOTE: The PKGBUILD.patch.txt patches applies to Artix' galaxy/yaourt, not to upstream yaourt (aur/yaourt).

Fixed some issues with the patch:
  • Passing through errors,
  • checking if svn is available.

Also, the PKGBUILD got a facelift, adding subversion as optdepend.

The updated files are now in the "original", edited post.

Re: Adapt yaourt to honour Artix' repositories?

Reply #11
This is yaourt -Syy no patches what am I missing here as it works fine

You are getting binary packages. Try to get a package source:

Code: [Select]
yaourt -G world/ffmpeg

for example.

Re: Adapt yaourt to honour Artix' repositories?

Reply #12
May I suggest renaming it to yaourtix? Perhaps it could be included in [galaxy], when sufficiently tested.

Do you want to maintain? And put to the AUR? Feel free!

.. I really wish that repo <-> download URL/ download method can be configured in a configuration file, to also allow for other (unofficial) repositories, but since I had no real need for this up to now I did not try to code it (much more work than just making some crude hacks to the already existing scripts).

Also, the yaourt maintainer seems lazy; a longer time ago I already requested upstream to make yaourt abort if customizepkg fails; up to now it silently continues ... there was now answer at all.

Re: Adapt yaourt to honour Artix' repositories?

Reply #13
Unfortunately, I can't maintain it due to time constraints. Why don't you create a pull request at github? I may have some free time during the weekend and merge it.

Re: Adapt yaourt to honour Artix' repositories?

Reply #14
Unfortunately, I can't maintain it due to time constraints. Why don't you create a pull request at github? I may have some free time during the weekend and merge it.

OK, maybe I will do some time. For up to now, I do know only very rudimentarily what a pull request is and I don't know how to do it. (And I also do not know more git than I need to get the latest state of software someone else has written). Is it much more easier to accept/ merge/ howeveritiscalled a pull request than to just patch in the patches and make a new git commit on your side? (Or is there another thing I am not aware of right now?) -- OK, this goes offtopic, since it goes into version control/ software development practices basics.