Message ID | 1426736888-29437-5-git-send-email-steven@uplinklabs.net |
---|---|
State | Changes Requested |
Headers | show |
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.
diff --git a/package/Config.in b/package/Config.in index c557010..95ec454 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1261,6 +1261,7 @@ endmenu menu "Package managers" source "package/ipkg/Config.in" source "package/opkg/Config.in" + source "package/pacman/Config.in" if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS source "package/rpm/Config.in" endif 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 + select BR2_PACKAGE_LIBGPGME + select BR2_PACKAGE_LIBARCHIVE + select BR2_PACKAGE_LIBCURL + select BR2_PACKAGE_OPENSSL + 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 +PACMAN_DEPENDENCIES = glibc libarchive libcurl libgpgme openssl +PACMAN_LICENSE = GPLv2 +PACMAN_LICENSE_FILES = COPYING + +$(eval $(autotools-package))
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