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

Templates, xbps-src etc


Sorry if I’m being thick, but I need some clarification.

I gather there’s no equivalent to Arch’s makepkg -si for PKGBUİLDs in Void for templates, at least as simple as Arch’s, right?

xbps-src is seemingly, according to the wiki, for purposes of creating and submitting packages for Void itself, it’s not a simple equivalent to makepkg?

So to be able to install some packages I need to wait for their templates submitted by contributors in github to be approved and then offered as binaries?


With xbps-src you can build packages from source for your personal use.
You don’t have to wait for new templates, you can create & use your own templates! (there are examples on this forum.)


Yes, but it seems too involved. I don’t even have xbps-src, probably have to install xtools etc. It’s much easier to just compile without any xbps involvement. Well, anyway thanks.


makepkg -si” does not involve pacman ? :frog:


Well, makepkg -si is the most simple way, but the Void way, that is, the xbps-src way (presuming the wiki to be well-written and accurate) is too complicated for a plain user (tweaker). Either it is intended for official package building and submission, the local usage being just a by-product (which is my understanding) or it can be used as easily as xbps-src template too in which case the wiki is not well-written –if I’m not blind!

(Masato the Empty) #6


This is actually what xbps-src runs after building and dest-installing software. It’s how I built a few packages for myself before I started using xbps-src.

You build your software, install it to a temporary destdir, then run xbps-create to box it up into an .xbps archive. Check the man page for details on its usage.

One thing that may not be in the man page (it wasn’t last I checked) was regarding pre/post-install/remove scripts or installation messages like you see with some packages. Turns out, all you need are the specially-named files copied to the top level of the temporary destdir (I got this from looking at how xbps-src invoked the command). The files for scripts and messages are documented in the xbps-src manual.


Thanks @masato for reminding me of xbps-create !
I forgot about that option, which you have already mentioned on other topics! :thumbsup:

It’s not so complicated, it just takes getting used to. :mountain_bicyclist:

You can.
But nothing’s stopping you from doing unofficial things. :grin:

(Masato the Empty) #9

Some time ago, I’d sort of forgotten myself, since I decided I liked the way xbps-src worked… But I realized that if it doesn’t offer anything you want in particular, xbps-src is just another layer in between you and your software build. I started thinking especially about people who might not be as familiar with package building in general. Better to get used to downloading tarballs and following the build instructions; then you can tackle build automation a bit later on.

In between, learning how to install to an alternate location and then wrap that up into a binary package helps with the management side of things (it feels much better than keeping around all the configured source trees and makefiles to do make uninstall… when you want to remove or upgrade something)


I guess this is a known bug of the forums page: the second time my reply has vanished. I had thanked for the above suggestions.


I really wish there was a concrete example / tutorial for xbps-src the last time I looked at it, I was left scratching my head…


May I piggy back (or hijack) with few beginner questions:

1 - say someone creates template for personal use for browser Vivaldi or Brave… and post template here on the forum. Q: will this template work over time as is or it will need to be maintained, changed often?

2 - since there are a few, which is a preferred way of building template/package?

(Masato the Empty) #13
  1. I don’t think there would be a blanket rule. It depends on what the package needs, and what changes in the rest of the system will affect it. Some pieces of software will need to be updated regularly to keep working as their dependencies are updated in ways that break the existing versions. Other pieces of software can go years without an update or patch, so no changes to a template.
  2. There’s no preferred way as far as I can see. xbps-src is the only way to work if submitting packages to Void. If you’re not doing that, I know of at least one maintainer that has expressed his thoughts that there’s no reason not to simply do configure/make/make-install manually (or whatever the build instructions are for a particular program).

I personally prefer to have as little software as possible that’s not managed by the system package manager, so the first thing I learned to do was use xbps-create. When I decided to start working with existing packages, I got to like the idea of te isolated build environment offered by xbps-src.

I think you need to decide what works best for you. Perhaps it would be worth asking others why they use xbps-src or not (hopefully in a new thread, out of courtesy to the OP of this thread).


Thanks, masato; no problem for me, it’s still around the same subject.


Thank you for the reply and sorry for late respond, I was away

(Michael Aldridge) #16

Its worth pointing out that xbps-create is not designed to be driven manually. There are a lot of flags that have to be set to generate a functional package and that is why it is driven by xbps-src. As far as tutorials go, there’s Manual.md in the root directory of the xbps-src repo which describes how to use the xbps-src system to create packages.

I am perhaps one of a few maintainers that @masato might have been referring to above, in that I think if you aren’t trying to get your package accepted, why are you bothering with xbps-src? That would be like running a sprint and stopping just 1 meter before the finish line! At that point just ./configure ; make ; make install. Or curl|bash or whatever the latest hack is to install things.

(Masato the Empty) #17

Unless having even locally-built software managed by the package manager as much as possible is important to you. (it’s very important to me). Yeah, not everyone is going to care about that.

That may be true, but it’s nonetheless very effective and not difficult at all if the above is what you’re after. I was using it within weeks of switching to Void. It was a hell of a lot easier than figuring out dpkg, that’s for sure. (actually, I quickly slapped together a dirty script that took a config file for a piece of built/destinstalled software and generated the right xbps-create command, just to make it a little easier to remember what metadata I wanted to include)


Why have such a nice and tidy distro like void and then mess it up? :wink: ./configure ; make ; make install might be ok for one or two things but if you have more you lose oversight eventually. Not to mention the hardening flags xbps-src applies automatically. If you want to use them without xbps-src you’d have to do some tinkering as well. I think once you have a grasp on how things work with xbps-src many packages are not hard to build. And it’s never wrong to learn how things work and are interconnected. :slight_smile:

Agreed, but what if there’s only a git version of some package and no release, e.g. Or you’d like to have a customized package tailored to your needs? And what if you submit a package but for some reason you cannot maintain it? Etc…

(Michael Aldridge) #19

I guess at the end of the day, my stance is:

Don’t waste my time with troubleshooting a package that you have no intent of merging.

I use the equivalence class ‘you’ above and do not refer to any individual in this thread or elsewhere.