Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always get the PKGBUILD from trunk, not from repos #1843

Closed
kiufta opened this issue Dec 1, 2022 · 6 comments
Closed

Always get the PKGBUILD from trunk, not from repos #1843

kiufta opened this issue Dec 1, 2022 · 6 comments
Labels
beginner friendly Beginner friendly issues that are easily coverable through unit tests help wanted Status: Approved Feature Request or Enchancement has been approved. Type: Feature Request

Comments

@kiufta
Copy link

kiufta commented Dec 1, 2022

When I use yay on a package from ABS e.g. yay -G haskell-glob I'll get

.
├── repos
│   └── community-x86_64
│       └── PKGBUILD
└── trunk
    └── PKGBUILD

I'd be satisfied with a single PKGBUILD. How do I advice yay to ignore any other sources than trunk?

The behavior of yay -Gp is great, not giving me a tree of PKGBUILDs.

Thanks in advance!

@kiufta kiufta added Status: Discussion Open Topic is being considered and open for discussion Type: Feature Request labels Dec 1, 2022
@kiufta kiufta changed the title Always the PKGBUILD from trunk, not from repos Always get the PKGBUILD from trunk, not from repos Dec 1, 2022
@stale
Copy link

stale bot commented Apr 2, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 2, 2023
@Jguer Jguer added help wanted Status: Approved Feature Request or Enchancement has been approved. beginner friendly Beginner friendly issues that are easily coverable through unit tests and removed stale Status: Discussion Open Topic is being considered and open for discussion labels Apr 3, 2023
@tchaudhry91
Copy link
Contributor

Hi, I'm working on a PR for this.
A couple of questions:

  1. For getting only the trunk, is it the same as downloading from HTTP (like in -Gp) and forego git completely? Because I don't see a method of checking out only specific files via git.
  2. Is concurrent check-out still worthwhile in this case like in the git repos download?

@Jguer
Copy link
Owner

Jguer commented Apr 14, 2023

Hey @tchaudhry91 , thanks for taking a look at this

  1. if you use HTTP you'll miss extra files that might be needed to build the package (.patch files in the pkgbuild repo)

  2. concurrency is not a priority

@tchaudhry91
Copy link
Contributor

@Jguer
Okay then I could probably re-use the existing cloning mechanism (so, concurrency is question is moot anyway).
But the only way I see to achieve this is, clone and the "clean" the cloned repo.

  • Clone per usual
  • Remove everything other than trunk
  • Move everything from trunk to directory root
  • Remove trunk
  • Remove .git (because we've mutilated the clone anyway)

I almost have this bit done. Will add a PR soon, can rework it if needed.

The other option is to do a sparse checkout (but that still downloads the whole repository, just restricts the checkout from what I can tell) and will need a bunch of chained git commands instead of a single clone. In general it seems more hassle than required.

If there is any other suggestion, let me know.

@Jguer
Copy link
Owner

Jguer commented Apr 14, 2023

There is an alternative fancy way that was implemented at some point but then reverted for some reason.

  1. clone repo to yay cache
  2. ln -s the trunk to the wanted directory

when the user tries to fetch the same package, you fetch/merge the upstream to the local cache (how yay does for AUR installs and link it again

🤷 try it out if you want

@Jguer
Copy link
Owner

Jguer commented Jun 24, 2023

Closing with mirror changes

@Jguer Jguer closed this as completed Jun 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beginner friendly Beginner friendly issues that are easily coverable through unit tests help wanted Status: Approved Feature Request or Enchancement has been approved. Type: Feature Request
Projects
None yet
Development

No branches or pull requests

3 participants