[cr0sh]

Arch isn't that hard to set up - I'll agree with you there. Where it falls down, though, is when you need to install something where there isn't a package for it.

Now, of course, you could just go old-school and "manual install" whatever you want. But let's say you didn't want to do that, because you got tired of having a system full of cruft due to all these funky pieces of software scattered about the system that the package manager had no clue about - oh my!

So - you want to install the software as a package under Arch. Oh - and just to make things more fun, the software is something proprietary and closed-source. There is more than a few bits of useful Linux software out there like this - much of it niche areas where a) probably no one else in the Arch community uses, and b) it's proprietary - so you can't distribute it anyhow.

What does Arch require you to do in this situation? Well - last time I looked anyhow - and that was a couple of years ago, so maybe something has changed... It seemed to me to create an install package for a piece of software, the process (according to the docs) was to install the software "manually" and keep track of where everything goes. Then, once you have done that (and the software is running fine), you are supposed to create your package manifesto (or whatever it was called) that tells the system how to install it, then take all the parts and bundle them up (as a compressed file of some sort) with that manifesto. Oh - and then manually "uninstall" your software you installed, then use your new package to re-install your now-packaged proprietary software.

That's basically the process I read about for any kind of software package for Arch; it was a very heavy manual process. While other package management schemes do require some manual effort, none of them that I recall seemed to require as much effort as Arch's did. This wouldn't normally be an issue with most open-source software, because once you made that package, it could be distributed and used by the community. But for a proprietary software package, only you could use it - so it was a ton of extra work for little gain in the end.

Don't get me wrong - I liked Arch, and their community support and forums, wiki, etc - is pretty top-notch (I like to use that part of the ecosystem myself for help and hint purposes when I need it). I honestly think it is a great distro, but it does have some drawbacks to it (and they probably don't have good solutions, either).

[wallacoloo]

> It seemed to me to create an install package for a piece of software, the process (according to the docs) was to install the software "manually" and keep track of where everything goes. Then, once you have done that (and the software is running fine), you are supposed to create your package manifesto (or whatever it was called) that tells the system how to install it, then take all the parts and bundle them up (as a compressed file of some sort) with that manifesto. Oh - and then manually "uninstall" your software you installed, then use your new package to re-install your now-packaged proprietary software.

This might be technically correct (not completely sure), but hugely misleading. Packages are defined by PKGBUILD scripts. When you run `makepkg` to create a package, it creates a directory called $pkgdir. In your PKGBUILD, you just delegate to whatever installer came with the source code & tell it to install into $pkgdir. e.g. `make install --prefix=$pkgdir`. makepkg takes all the files in $pkgdir and tars them and bam - there's your package.

If you look in most PKGBUILDs, they contain some metadata (where to get the sources, etc), and then it's more or less:

    build() {  
        cd "$srcdir" && make  
    }  
    package() {  
        cd "$srcdir" && make install --prefix="$pkgdir"  
    }

That's all you need for quite a few packages.

[JdeBP]

cr0sh posited that the application being packaged was not in source form. So perhaps the hugely misleading thing is to argue against xem based upon how one packages up things that are in source form. (-:

[wallacoloo]

Well as long as it ships with an installer, the above method still works - just omit the build step altogether (do a chroot if the installer doesn't offer a choice of where to install). If it doesn't have an installer, but comes self-contained, then just `cp $srcdir $pkgdir/opt` & call that good.

And if you're dealing with a non-source package that doesn't have an installer and isn't self-contained, then installing/packaging it is difficult on any OS - not just Arch!

For reference, here's a PKGBUILD for a non-source, proprietary application. It's pretty much as above, but includes some fancy .desktop files & such, too. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=disco...

[JdeBP]

In fairness, that's pretty much how you are going to have to package a binaries-only software with most package management systems. Install the binaries. Make a package description of those binaries.

It's manifest, by the way.

[minitech]

Way more painful to make packages for Debian, IME, but I avoid making packages altogether:

> Now, of course, you could just go old-school and "manual install" whatever you want.

Yep, stop right there, do that.