I'm glad this has stirred some interest! =D
These are good concerns and good things to be talking about, I'll share a little more of my experience.
The binaries and instructions I posted are just the first way I tried that has worked consistently, but I'm hoping for this just to be a starting point - there is lots of room to improve, and I think integration into PPM or UPM with full dependency resolution is very realistic!
The reason I chose these specific tools is they are for one simple, and are also able to do the process of repo syncing/downloading/patching/compiling/packaging while keeping the process totally separate from actual package management, and it works great doing it by hand this way, it just takes a little interaction. That said, I'm pretty sure there are existing tools in Arch that would suit our needs better then this and make integrating it into one of our package managers more realistic. I'm testing different ones, and will report back with progress. PBfetch is looking very promising! (It's also 100% bash so very easy to tweak)
https://github.com/dalingrin/pbfetch/bl ... er/pbfetch
@fathom (thanks for the bump!)
I've build quite a few libs as well as apps, but ONLY when that lib doesn't exist in Porteus/Slackware (I check first, in that order) If it's something important like python3 or jack, I will check Alien and SBo too. I've had zero issues with libs cause I'm careful, but could definitely see how a user could accidentally bork their system. Ideally if this was wrapped into a gui, it would search Porteus/Slackware first and warn the user if the lib was available from there first
@brokenman
1) Good point. This is an easy one, I'll make sure xzm modules are named properly once I find a way to automatically create them after compiling a package
2) The AUR is one giant build script repository that is a similar idea to SBo, except maintained very actively by the community and completely massive. There is a big amount of community involvement, for instance people vote packages up, flag packages out of date, etc., and every package has a comments section beneath it and most have semi active discussions going on. Although the community does an amazing job, you are strongly encouraged to examine the PKGBUILD (Arch's version of a .Slackbuild) before building, and many of the helper apps make you look at it before proceeding. If you uploaded malicious code, it would be discovered QUICK
3) Yes! All the Arch tools I have used search the online database rather than a local one (probably because a there's a new package every few minutes) I don't think you can do this yet with the modules I made, that is, searching Arch proper as well as the AUR for a package and returning a list of matching packages with descriptions, but pbfetch does this beautifully, I will try to put an xzm of it up tonight
4) I think this will be possible with a small amount of effort! PKGBUILDS list their dependencies like this:
or with required versions:
or
Code: Select all
depends=('foobar>=1.8.0' 'foobar<2.0.0')
There is also a separate section for build dependencies and optional ones too.
Is that enough info for PPM/USM to figure the rest out?
5) Agreed, makepkg will need to be renamed and any helper scripts modified to use the new name before this thing gets any kind of major use
Have a quick look at a these pages and a sample PKGBUILD to get an idea of how they do it
https://wiki.archlinux.org/index.php/PKGBUILD
https://projects.archlinux.org/svntogit ... kages/nano
https://wiki.archlinux.org/index.php/AU ... Guidelines
