Yay: [Feature Request] Local "AUR repository" / Local packages from PKGBUILD

[c0d3z3r0]

It would be great if yay would support a local repository or install from a local PKGBUILD.

This is very useful for PKGBUILD one doesn't want to put in AUR. For example I build my kernel with a highly customized PKGBUILD but I always have to manually check if there is a new version available in git and then build it with makepkg.

There could be two concurrent types of local packages:

1. local "AUR" repo
   For example /home/user/repo that could be added via config. The packages could be appear as 'local/package' or 'local-REPONAME/package' just like 'aur/package'.

2. single manually installed packages
   Installation via yay -S local:///home/user/package.git where the PKGBUILD of the single package is located at /home/user/package.git/

[Morganamilo]

Local repositories are already a pacman thing but it seems like you mean something totally different, which would make it easy to confuse the both.

This all seems a little over complected though. Sure being able to do yay -U pkgbuild would be nice but at that point we are no longer a AUR helper. And given that we rely solely on the RPC, we'd need to implement dep resolving via srcinfos on top of via the RPC.

Also apart from -git packages, maintainers have to bump the pkgver themselves, so they already know there is an update, no need for yay to tell them.

Running a -git kernel though, wow you sure like living on the edge.

[c0d3z3r0]

Local repositories are already a pacman thing but it seems like you mean something totally different, which would make it easy to confuse the both.

Yes, I meant a "local AUR".

This all seems a little over complected though. Sure being able to do yay -U pkgbuild would be nice but at that point we are no longer a AUR helper.

It would be an additional feature to make yay being a "all-in-one package manager" or so.

And given that we rely solely on the RPC, we'd need to implement dep resolving via srcinfos on top of via the RPC.

Indeed.

Also apart from -git packages, maintainers have to bump the pkgver themselves, so they already know there is an update, no need for yay to tell them.

Ok, I didn't think of non-git packages... I my case it's only -git packages. This is the only case where this feature would help.

Running a -git kernel though, wow you sure like living on the edge.

Offtopic but yes ;) It's not only the kernel. I have some more -git packages I'd like to get updated by yay.

Hmm... maybe this really is a bit more complicated than I thought

[c0d3z3r0]

_To make things a little easier yay could support just install from PKGBUILD without using a .SRCINFO but getting dependencies directly from PKGBUILD._
Edit: forget this idea... SRCINFO is needed because of such things like source=('.......$pkgver....')

A local "aur repo" may be a bit too much. Since one knows which packages one has there is no need for a repo. That repo would be useful if there is one PKBUILD package depending on another. This dependency could be solved manually - just print an error and request the user to specify the PKGBUILD of the dependency, too.

The RPC is used to get depends and makedepends from .SRCINFO. Resolving those is done locally, isn't it? What a

[AladW]

AUR packages are git repositories. Any PKGBUILD can equally be put into a git repository. Use the facilities of git instead of trying to kitchen sink-ize your AUR helper.

[c0d3z3r0]

@AladW Of course they are. I did not say anything else. Read my first post again, please ;)

[AladW]

Looking at it again you probably want to check upstream directly, rather than archweb. aur-out-of-date might fit that.

[c0d3z3r0]

@AladW no. You didn't read 'til the end of the sentence.... "and then build it with makepkg."

aur-out-of-date is what yay already does when updating -git packages from AUR.

I want yay to do exactly what it does for AUR packages but with a local git repo (yes, with the PKGBUILD in it... no, not the source - just like AUR).

[AladW]

So you want yay to handle any use-case that can be trivially implemented using external tools and a 3-line bash script?

[c0d3z3r0]

"3-line bash script" would maybe work for ONE package!

I want to MANAGE all my packages with yay, that is binary packages, aur packages and local PKGBUILD files. So I would just have to do a yay -Syu to update everything just as yay does now for binary packages and aur packages.

But hey, why use yay at all when I can do EVERYTHING WITH "external tools and a 3-line bash script"...?

[AladW]

Yeah, and I want yay to do my dishes and file my taxes too.

But hey, why use yay at all when I can do EVERYTHING WITH "external tools and a 3-line bash script"...?

Never claimed that dealing with AUR can be done that way. Your "local PKGBUILD", at least by your vague descriptions, can.

[c0d3z3r0]

Why are you so narrow-minded?! Someone started developing yay to make things easier. When everybody thought like you there would be NO tools at all.

[AladW]

There's a difference between being narrow-minded and expecting every tool to handle every possible use case, no matter how related or unrelated to the original purpose. This is Arch Linux, not GNU.

[c0d3z3r0]

Never claimed that dealing with AUR can be done that way. Your "local PKGBUILD", at least by your vague descriptions, can.

Damn. Yes, of course, you could handle ONE PKGBUILD with a simple script. What about having 20?

There's a difference between being narrow-minded and expecting every tool to handle every possible use case. This is Arch Linux, not GNU.

This was just an idea for an additional feature. If YOU don't like it does not mean everybody else is not allowed to like it.

[AladW]

If YOU don't like it does not mean everybody else is not allowed to like it.

You've barely described what your "idea" is in the first place. As it stands, you said you have a linux-git PKGBUILD that you modified, and you want to keep it updated with upstream. That can easily be done with aur-out-of-date, like I said.

Why don't you start sharing some concrete PKGBUILDs and workflows instead of vague descriptions?

[c0d3z3r0]

That can easily be done with aur-out-of-date, like I said.

No it can't because aur-out-of-date checks if an AUR packages is out of date. As the name already states. The PKGBUILDs I am talking about are LOCAL and not in AUR, as already said more than once.

I don't have modified AUR packages only but also custom PKGBUILDs where I always have to do a manual makepkg (after modification, git commit etc. of the PKGBUILD repo) for about 20 packages.
Yes, of course... bash script... for loop ... makepkg etc. - I know....

I agree, it is not an every-day or normal-user use case but I don't think I am the only one with that use case.

[AladW]

No it can't because aur-out-of-date checks if an AUR packages is out of date.

If you read the aur-out-of-date readme you'll notice it supports local files.

Some more tools of relevance that can also modify PKGBUILDs automatically:

https://wiki.archlinux.org/index.php/AUR_helpers#Maintenance
https://github.com/xyproto/setconf

[c0d3z3r0]

If you read the aur-out-of-date readme you'll notice it supports local files.

My fault. I missed the --local SRCINFO.

Some more tools of relevance that can also modify PKGBUILDs automatically:

All this wasn't about modifying PKGBUILDS but updating locally installed -git packages just like AUR packages...

[AladW]

I'm guessing there's some language barrier here since in your previous post you mentioned PKGBUILD modification, and now it's suddenly not relevant. Anyway, can does not imply must.

[c0d3z3r0]

I'm guessing there's some language barrier here since in your previous post you mentioned PKGBUILD modification, and now it's suddenly not relevant. Anyway, can does not imply must.

Oh, I'm sorry, this was indeed unclear... I don't want yay (or any other script/tool) to modify my PKGBUILD but just detect (via git) that it has changed - exactly what is done for AUR packages.

[AladW]

Okay, I see what you mean now. That would then be a case of modularity: you'd want yay's version comparison abilities to not be restricted to the AUR, but to arbitrary PKGBUILDs (of which AUR PKGBUILDs are a special case). Not sure how complex this would be to implement with the current yay design. I did this in aurutils simply by using an independent program for VCS packages.

[c0d3z3r0]

Yes! :-)

Am 21.08.2018 um 21:45 schrieb Alad Wenter [e-mail]:

Okay, I see what you mean now. That would then be a case of modularity: you'd want yay's version comparison abilities to not be restricted to the AUR. Not sure how complex this would be to implement with the current yay design.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Morganamilo]

Closing in favour of #694 as its more to the point in what I'd be willing to add.

[ixil]

I'm not suer if #694 and this are quite the same thing

I made a little script today that may be of some use for people later on that may be of use:

I used it through first running yay -Syu - --timeupdate pkgPullingInBrokenDependencies
Then adding as a remote, or a branch for the pkgfile of relevance
Running the script and then using with yay --noredownload --save and yay -Syu - --timeupdate pkgPullingInBrokenDependencies

#!/bin/bash

cache_dir="$HOME/.cache/yay"
FILES="pkg1
pkg2
pkg3
"

for pkg in $FILES
do
    path="${cache_dir}/ros-melodic-${pkg}"
    echo "$path"
    cd "$path" || { >&2 echo "${path} failed!" ; exit 1; }
    git remote add -f 'better' "https://github.com/example/${pkg}"
    REF="$(git for-each-ref --sort=committerdate refs/heads/ --format='%(refname:short)' --count=1)"
    echo "$REF"
    git checkout -b example "example/master"
    unset REF

    cd "${cache_dir}" || { >&2 echo "failed to jump out! escaping" ; exit 1; }

done