sharpetronics/yay
1
0
Fork 0
mirror of https://github.com/Jguer/yay.git synced 2025-10-04 00:03:11 -04:00
Code Issues Projects Releases Wiki Activity

cleanup

Browse Source
This commit is contained in:
Sebastian Korotkiewicz 2025-09-27 03:58:32 +02:00
parent 529d21c71d
commit 980497c25f
No known key found for this signature in database
GPG Key ID: 5BDC557B496BDB0D
1 changed files with 0 additions and 183 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

183
TODO.md
View File

@ -1,183 +0,0 @@
# Feature Request: Support for Custom PKGBUILD Repositories
## Summary
Add support for configuring custom PKGBUILD repositories alongside AUR, allowing users to maintain private or organization-specific package collections that integrate seamlessly with yay's search and installation workflow.
## Motivation
Currently, yay is tightly coupled to the official AUR infrastructure. While this ensures consistency and security, it limits flexibility for users who want to:
- Maintain private PKGBUILD collections for proprietary software
- Create organization-specific package repositories
- Host custom packages that don't belong in the public AUR
- Develop and test packages locally before submitting to AUR
- Mirror or fork AUR packages with custom modifications
Users currently work around this limitation by:
- Creating wrapper scripts around yay
- Manually managing separate PKGBUILD directories
- Using complex build systems that bypass yay entirely
## Proposed Solution
### Configuration Format
Extend `~/.config/yay/config.json` to support custom repositories:
```json
{
"customRepos": [
{
"name": "company-internal",
"type": "git",
"url": "https://git.company.com/pkgbuilds",
"searchable": true,
"priority": 1
},
{
"name": "local-dev",
"type": "local",
"path": "/home/user/dev/pkgbuilds",
"searchable": true,
"priority": 2
},
{
"name": "mirror-aur",
"type": "http",
"url": "https://my-server.com/aur-mirror",
"searchable": false,
"priority": 3
}
]
}
```
### Repository Types
**Local repositories (`type: "local"`):**
- Point to local filesystem paths
- Expected structure: `repo-root/package-name/PKGBUILD`
- Immediate availability, no network dependency
**Git repositories (`type: "git"`):**
- Clone/update git repositories containing PKGBUILDs
- Support for authentication (SSH keys, tokens)
- Cached locally for offline access
**HTTP repositories (`type: "http"`):**
- Simple HTTP-served directory structures
- Lightweight alternative to full AUR infrastructure
- Compatible with static file hosting (nginx, Apache, GitHub Pages)
### Expected Repository Structure
```
repository-root/
├── package-a/
│ ├── PKGBUILD
│ ├── .SRCINFO
│ └── [additional files]
├── package-b/
│ ├── PKGBUILD
│ ├── .SRCINFO
│ └── [patches, sources, etc.]
└── [optional] packages.json # metadata for faster searching
```
### Integration with Existing Commands
**Search (`yay -Ss <query>`):**
- Include results from configured custom repositories
- Clearly indicate source repository in output
- Respect priority ordering
**Install (`yay -S <package>`):**
- Check custom repositories before falling back to AUR
- Support repository-specific installation: `yay -S repo/package`
**Information (`yay -Si <package>`):**
- Display repository source and metadata
- Show if package exists in multiple repositories
### Security Considerations
- Add configuration option to restrict custom repositories to trusted sources
- Warn users when installing from non-AUR sources
- Implement signature verification for HTTP repositories
- Sandboxed builds by default (existing yay behavior)
## Example Use Cases
1. **Company Development:**
```bash
# Search includes both AUR and company packages
yay -Ss company-tool
# Install from specific repository
yay -S company-internal/proprietary-software
```
2. **Local Development:**
```bash
# Test local PKGBUILD before AUR submission
yay -S local-dev/my-new-package
```
3. **Custom AUR Mirror:**
```bash
# Use organization's AUR mirror with modifications
yay -Ss modified-package
```
## Implementation Considerations
### Backward Compatibility
- Default behavior unchanged when no custom repositories configured
- Existing configuration files remain valid
- AUR remains the primary source unless explicitly overridden
### Performance
- Cache repository metadata locally
- Implement incremental updates for git repositories
- Parallel searching across repositories
### User Experience
- Clear indication of package sources in output
- Intuitive error messages for repository access issues
- Optional repository management commands (`yay --repo-add`, `yay --repo-list`)
## Alternative Approaches Considered
1. **Wrapper Scripts:** Users currently implement this functionality externally, but it requires maintaining separate tooling
2. **Fork yay:** Creates fragmentation and maintenance burden
3. **Different AUR Helper:** Switching tools loses yay's established feature set and community
## Related Issues
- Users frequently request support for private/custom package sources
- Organizations need better package management for internal tools
- Developers want smoother workflows for package development
## Benefits
- Maintains yay's unified interface while adding flexibility
- Enables enterprise and development use cases
- Strengthens Arch Linux ecosystem by supporting diverse packaging needs
- Reduces need for complex workarounds and fragmented tooling
This feature would make yay more versatile while preserving its core strengths and maintaining compatibility with existing workflows.
$ yay -Sy
:: Synchronizing package databases...
core is up to date
extra is up to date
multilib is up to date
:: Updating custom repositories...
company-internal: Updating... done
local-dev: Updating... done
{
"name": "company-internal",
"type": "git",
"url": "https://git.company.com/pkgbuilds",
"branch": "main", // opcjonalnie
"auth": { // opcjonalnie
"type": "ssh_key" // albo "token", "basic"
}
}