Home | News | Download | Packages | Forum | Wiki | Github

Void User Repository


(Aditya Goturu) #1

Hi
Anyone interested in joining me in a quest to create a void linux user template repository with support for dependencies on other user templates? Like the AUR?
Here’s my plan:
PHP Based Webapp that handles the upload and serving of tarballs/templates. Use a service like mirrorbrain or similar on the backend.
Frontend app similar to yaourt/packer. Written in C, to keep everyting as snappy as the rest of the XBPS suite. Basically download template, check deps, download any required deps in template, pull in deps from xbps, compile everything, setup local xbps repo and install. I was thinking a copy of void-packages and maybe void-packages-bleeding-edge should be kept in a folder /var/lib/xbps-builder or similar.
Thoughts?


(Benjamin) #2

No :thumbsdown:. I don’t think we need anything like this, all you really have to do to get a package in the main repo is to create a template. Then you got to just send a PR to the void-packages repo on github, and wait for it to be reviewed then merged.


(Aditya Goturu) #3

I just spent 12 minutes trying to type up a counter, and backspaced each one out, because, well, you have a very valid point. This is why I thought it might be a good idea to put this up before starting work on the thing.


(deepdark) #4

I agree with @The_Doctors_Life, please no AUR-alike. That problem is already solved in Void and more elegantly as Benjamin explained.


(Aditya Goturu) #5

I was wondering, on average, if a package is perfect (meets standards, complies fine etc), how long does it take to get from pr to main repo?


(Benjamin) #6

A day or less, the maintainers are quite active.


(Michael Aldridge) #7

I additionally disagree with this proposal. The entire point of void is that things are coming from one repo that is up to date and stable. Its really not much work to get your package into the repo if it meets the standards.


#8

Point me in the direction I need to go in order to accomplish this, please?


#9


and

would be a start


#11

I would acually be good with something like this, VUR :slight_smile:


#12

Sorry to bring this topic back, I would like to throw some ideas out. As it has been said, no AUR alike. One of the advantages that void presents is the fact that packages are reviewed by maintainers, keeping the quality of the repos high, which is a great thing and rather tiring job, but precious tho the community!

However, I see there is a big problem, specially in the long run. Everything needs to be done by the maintainers, their time and their resources. Requests are piling up and the hardware is not free, old packages are barely keep due to space limitations, which isn’t great; x86, arm, arm64, x86_64 (an mips?) need to be stored and compiled, generating costs. And Void will only continue to grow, making this worse and worse.
Another issue is that reviewing a package is sometimes not enough. Knowing which make flags should be used or not, special compiling options, etc (specially when having a musl branch). A build may work in a machine, but may not in others, and it may set some settings that the majority may not want (example: requiring Java for a minor feature). But if the package is approved then any issue it causes, even if it wasn’t created by the user (an update), then needs to be fixed by them, the maintainers.
My last concern is wether the smallest and strangest packages will need to have support. There are little utils that some people may use, but throwing them into the official repos may be too… extreme. AUR solves this problem (one of the few things that it does right), it allows user to share automatic installation instructions (PKGBUILDs). Void could take advantage of that.

I would like to throw some proposals out:

  • Accepting any package (after being approved), but without building it: users can continue to contribute to void-packages, but flaging it as a no build package by the continuous building system, but still letting the user to clone it and build it from source if needed. This way a bit of resources are saved.

  • Separate repository for the community: similar to the idea of AUR, like a VUR. but packages need to pass the maintainers and packagers approval, and is treated like the current void-packages. Users will need to clone it and build their extra packages from there, without an easy manager like Pacaur or yaourt.

The main difference between the two is that the second would be closer to the community. There will be filtering, but a package creator could directly modify their own package, like AUR. But the maintainers would still have the right to deny someone from uploading or modifying anything.

The advantages this method presents is a faster growing package number. But I am more interested in testing. This way we could have automated *-git packages ready to be build, clean and easy (take dolphin’s emulator as an example, 3 years passed from stable to stable release, but the development branch was miles ahead after some time passed, and people used the -git branch).

All feedback is welcome.


(Masato the Empty) #14

It could just be a matter of getting an easy and (at least somewhat) organized way of sharing xbps templates.

I see how it could be useful. Perhaps something as simple as a specific thread category on the forum for user-created templates and alternate build instructions. (that’s for those of us who don’t maintain our own fork of void-packages).

Best to keep it as informal as possible. I have a handful of packages that I build on my own from my own templates and I wouldn’t mind sharing if anybody was interested (quodlibet/exfalso, gns3, hts plugin for kodi, PDKSH from openbsd). But I don’t request they be added to Void because

  • I don’t really know if a piece of software is really up to Void standards (one of which being that it’s useful to more people than just myself)
  • I feel like I should be the one to be responsible for the package in such a case, and I don’t want that responsibility (Void maintainers may not mind in many cases, but it’s my own personal feeling).

I’m horrible at tracking updates. I don’t rebuild my local packages until (I notice) they break or a feature is added that i need. Still, if anybody wanted it, I’d share what small work I’ve done.

So a dumping ground for such things wouldn’t necessarily be a bad thing.


#15

I am in a similar situation regarding maintainers managing my packages and me tracking their updates. To add some more points to my last post would be your situation. There are people who don’t want to maintain their fork of void-pakages, who just want a quick template to go. An open repository would be quite nice tbh. And that many people, much like you, who have created templates but don’t want to get into the packaging world would be able to share them with the community in an easy and ordered way.

Your idea to have a specific category is quite nice actually, informal, non-official but close to the community. A pinned post linking to all the packages would be very nice, though dirty.

And I just realized that Pkgsrc should work without much issues in Void. So if people need packages that are not found in void-packages they could use it. It’s not a perfect solution (messy), and Pkgsrc is far from complete and rolling release (even in their -current branch), but it is an easy to go option too.


(Masato the Empty) #16

You mean xbps-src? Or some other system named pkgsrc (not having used NetBSD, I’d find it logical if xbps is a direct descendent of NetBSD’s pkgsrc)

Actually, I find the rolling-release nature of void-packages isn’t really too hard to deal with on the little guy side of things. I make it a habit of doing first a git pull (or a stash-then-pull if I’ve been doing anything with existing packages) for the tree then a bootstrap-update for the build env before I start on a package.

Granted, this is really just for people who actually build software, and not for those who (don’t want | aren’t ready) to do that and just want binary packages but it’s a simple matter of market economics that if one product really doesn’t fit your needs, you should seek another product (and it doesn’t really have to be a reflection on either of the products). And honestly, I suspect that on occasion some of us would take a stab at making templates on request anyway.

So for people like us who just don’t like working outside of a distro’s package system (too many make installs just gets ugly after a while), I think a template exchange is just fine. And it shouldn’t require any special policy revision.

At present, there’s really nothing stopping us from opening threads offering our templates for those who are interested, and I really doubt any of the forum mods would say “hey, cut that out.” Only thing that would be nice is a specific category, so you could find all relevant threads by looking at the “xbps-src template dumping ground” category or some other similar use-at-your-own-risk-sounding name.


#17
  • tracking updates can be made pretty easy using the update-file inside the scrpkgs/ folder.
  • if someone adds functionality to a package, why not share that? for example: add a build option to the template for that feature / patch and open a pull request on that. that gives everybody the possibility to use your modification. it is indeed more simple that extracting a template by hand from a forum, as the xbps-src environment would still have to be set up…
  • If you contributed a package to the official repo, it would of course be nice if you keep it in sync with the upstream release, but if you don’t want to - then don’t! No need to feel that pressure i think. a lot of templates are updated by other people although they are originally contributed by someone else, who maybe doesn’t use void anymore, who knows? And if somebody complains over an outdated package, he can still go on and work it out on himself (after all most of us put in their work for free). That is what open source is about.

Bottom line: something like AUR is not implemented in void linux for a good reason. and if you post templates in a forum, you would still be “contributing” in a way, so you might feel responsible anyway to deliver usable stuff. Void’s quality guidelines are (at least part of) the reason why the system works that well while being maintained by a relatively (compared to an other big rolling-release distro with a big group of maintainers) small group of people.
You see: i don’t really see the point in not sharing something already created, but still sharing it. :wink:


(Masato the Empty) #18

Absolutely agree, which is why I like the idea of an area for xbps template exchange just on the forum (in its own little seedy area so they can always be found).

Some ask why, others ask why not. (Many of the former definitely appreciate and even admire the latter!).


(Masato the Empty) #19

Side thought: Anybody think that the “Void User Repository” topic may be a bit poisoned now? Perhaps a topic fork is in order.


(Artsiom) #21

We have something like void user repository, but decentralized. It is only for git versions of packages


(Michael Aldridge) #22

This is a long running topic that seems to have changed substantially over its life. I’ve set the auto close to 2 weeks, any furthur discussion should really happen in a new thread.

As far as the mention of GNS3, my template is at review quality, its up for merging in ~4 days.

A more general reply:
Long story short, my opinion as a maintainer and as one of the people that oversees the infrastructure of the repos is that nothing good can come of a user repository. Ultimately, if your template isn’t able to meet the very low bar set for merging back to void-packages, you are probably better off not bothering with a template at all and just compiling from source in your running system.


(Benjamin) #23

A post was split to a new topic: Void User Template Repository