package: add pacman 4.2.1

This is the Arch Linux package manager.

Signed-off-by: Steven Noonan <steven@uplinklabs.net>
---
 package/Config.in        |  1 +
 package/pacman/Config.in | 18 ++++++++++++++++++
 package/pacman/pacman.mk | 14 ++++++++++++++
 3 files changed, 33 insertions(+)
 create mode 100644 package/pacman/Config.in
 create mode 100644 package/pacman/pacman.mk

Hi Steven,

On Wed, Mar 18, 2015 at 08:48:07PM -0700, Steven Noonan wrote:
> diff --git a/package/pacman/Config.in b/package/pacman/Config.in
> new file mode 100644
> index 0000000..9c4ca66
> --- /dev/null
> +++ b/package/pacman/Config.in
> @@ -0,0 +1,18 @@
> +config BR2_PACKAGE_PACMAN
> +	bool "pacman"
> +	depends on BR2_TOOLCHAIN_USES_GLIBC

Why? Please explain in the commit log.

> +	select BR2_PACKAGE_LIBGPGME
> +	select BR2_PACKAGE_LIBARCHIVE
> +	select BR2_PACKAGE_LIBCURL
> +	select BR2_PACKAGE_OPENSSL

Please propagate dependencies.

> +	help
> +	  Pacman is the package manager used by the Arch distribution. It is a
> +	  frontend for the ALPM (Arch Linux Package Management) library.
> +
> +	  Pacman does not strive to "do everything." It will add, remove and
> +	  upgrade packages in the system, and it will allow you to query the
> +	  package database for installed packages, files and owners. It also
> +	  attempts to handle dependencies automatically and can download
> +	  packages from a remote server. Arch packages are simple archives, with
> +	  .pkg.tar.gz extension for binary packages and .src.tar.gz for source
> +	  packages.
> diff --git a/package/pacman/pacman.mk b/package/pacman/pacman.mk
> new file mode 100644
> index 0000000..e979adb
> --- /dev/null
> +++ b/package/pacman/pacman.mk
> @@ -0,0 +1,14 @@
> +################################################################################
> +#
> +# pacman
> +#
> +################################################################################
> +
> +PACMAN_VERSION = 4.2.1
> +PACMAN_SITE = https://sources.archlinux.org/other/pacman
> +PACMAN_SOURCES = pacman-$(PACMAN_VERSION).tar.gz

Default.

> +PACMAN_DEPENDENCIES = glibc libarchive libcurl libgpgme openssl

No need to explicitly depend on 'glibc'. glibc is part of the toolchain that 
is an implicit dependency of everything.

> +PACMAN_LICENSE = GPLv2
> +PACMAN_LICENSE_FILES = COPYING
> +
> +$(eval $(autotools-package))

baruch

Dear Steven Noonan,

On Wed, 18 Mar 2015 20:48:07 -0700, Steven Noonan wrote:
> This is the Arch Linux package manager.
> 
> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
> ---
>  package/Config.in        |  1 +
>  package/pacman/Config.in | 18 ++++++++++++++++++
>  package/pacman/pacman.mk | 14 ++++++++++++++
>  3 files changed, 33 insertions(+)
>  create mode 100644 package/pacman/Config.in
>  create mode 100644 package/pacman/pacman.mk

In addition to the comments made by Baruch, could you also include in
the commit log a motivation for adding this package in Buildroot?

It seems a bit weird to package the package manager of another distro.

Thanks,

Thomas

On Fri, Mar 20, 2015 at 12:52 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Steven Noonan,
>
> On Wed, 18 Mar 2015 20:48:07 -0700, Steven Noonan wrote:
>> This is the Arch Linux package manager.
>>
>> Signed-off-by: Steven Noonan <steven@uplinklabs.net>
>> ---
>>  package/Config.in        |  1 +
>>  package/pacman/Config.in | 18 ++++++++++++++++++
>>  package/pacman/pacman.mk | 14 ++++++++++++++
>>  3 files changed, 33 insertions(+)
>>  create mode 100644 package/pacman/Config.in
>>  create mode 100644 package/pacman/pacman.mk
>
> In addition to the comments made by Baruch, could you also include in
> the commit log a motivation for adding this package in Buildroot?
>
> It seems a bit weird to package the package manager of another distro.
>

Why do we have RPM then? :)

If we don't want it in there I have no problem maintaining it in my own tree.

Dear Steven Noonan,

On Fri, 20 Mar 2015 13:18:46 -0700, Steven Noonan wrote:

> > In addition to the comments made by Baruch, could you also include in
> > the commit log a motivation for adding this package in Buildroot?
> >
> > It seems a bit weird to package the package manager of another distro.
> 
> Why do we have RPM then? :)

Well, to be honest I don't know how rpm compares to pacman. I believe
the reason we have rpm and opkg is because some people might build
their own binary packages (outside of Buildroot, since Buildroot
doesn't allow building binary packages), and install them inside a
Buildroot system.

> If we don't want it in there I have no problem maintaining it in my
> own tree.

Well, it's that we don't want it, the package seems pretty simple, so
it's not that a big issue. It's just that it's a bit unusual, and some
explanations about the use case would be useful.

Thanks!

Thomas

On Fri, Mar 20, 2015 at 1:34 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Steven Noonan,
>
> On Fri, 20 Mar 2015 13:18:46 -0700, Steven Noonan wrote:
>
>> > In addition to the comments made by Baruch, could you also include in
>> > the commit log a motivation for adding this package in Buildroot?
>> >
>> > It seems a bit weird to package the package manager of another distro.
>>
>> Why do we have RPM then? :)
>
> Well, to be honest I don't know how rpm compares to pacman. I believe
> the reason we have rpm and opkg is because some people might build
> their own binary packages (outside of Buildroot, since Buildroot
> doesn't allow building binary packages), and install them inside a
> Buildroot system.
>
>> If we don't want it in there I have no problem maintaining it in my
>> own tree.
>
> Well, it's that we don't want it, the package seems pretty simple, so
> it's not that a big issue. It's just that it's a bit unusual, and some
> explanations about the use case would be useful.
>

OK, fair enough. Pacman is fairly generally applicable and could work
fine for Buildroot (just as RPM could).

I have two distinct use cases:

- PXE Arch Linux installer ramdisks (ArchISO is a bit too big for my tastes)
- Minimalistic virtualization hosts

First, I'd like to use Buildroot to create a minimal PXE booted
ramdisk to do automated Arch Linux installs -- in order to do that, I
need pacman + the arch-install-scripts.

And second, which may be part of a larger discussion to have: I also
envision Buildroot being used to create very stripped down Linux
installs for virtualization hosts, i.e. kernel + bare minimum
userspace + xen/kvm/lxc. Most Xen/KVM/LXC admins seem to use full
desktop/server Linux installs on their virtualization hosts, but this
is really unnecessary and often is disruptive to guest operating
systems. I would contend people should really treat the privileged
domain (host) as an embedded system, especially to avoid contention
between guests and the host. For example, why would you want mandb or
updatedb running via cron on your host when you'll never use the
fruits of their labor there? All those do is consume resources that
could otherwise be used by a guest, and introduce observable latencies
in the guest environments. As for how this relates to Pacman: in order
to act as a minimal LXC host, the various Linux distribution package
managers are needed for 'lxc-create' with a template (e.g. Fedora has
the Debian and Arch package managers available in their repositories,
as odd as that may seem at first glance). In the case of KVM and Xen,
you're just dealing with disk images, so it's not necessary to have
the other distros' package managers.