From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-40902-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1OAsZt-0000cN-Al
for garchives@archives.gentoo.org; Sat, 08 May 2010 22:32:57 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 9B34CE07CE;
Sat, 8 May 2010 22:32:50 +0000 (UTC)
Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74])
by pigeon.gentoo.org (Postfix) with ESMTP id B1C3BE07B6
for <gentoo-dev@lists.gentoo.org>; Sat, 8 May 2010 22:32:14 +0000 (UTC)
Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com [74.125.82.53])
by smtp.webfaction.com (Postfix) with ESMTP id C9D5F1C7714D
for <gentoo-dev@lists.gentoo.org>; Sat, 8 May 2010 17:32:13 -0500 (CDT)
Received: by wwi17 with SMTP id 17so208037wwi.40
for <gentoo-dev@lists.gentoo.org>; Sat, 08 May 2010 15:32:12 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.216.176.194 with SMTP id b44mr1192656wem.124.1273357932403;
Sat, 08 May 2010 15:32:12 -0700 (PDT)
Received: by 10.216.188.198 with HTTP; Sat, 8 May 2010 15:32:12 -0700 (PDT)
Date: Sun, 9 May 2010 00:32:12 +0200
Message-ID: <AANLkTimc-0KoQxdiqcZlMPw3kJMDpSlOh5TuKhu_0HD4@mail.gmail.com>
Subject: [gentoo-dev] Package managers and new repositories formats
From: Auke Booij <auke@tulcod.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: d8564c80-877c-4330-a926-279ea3635836
X-Archives-Hash: f1e19ee5d1da734c11580b65bda7ab7a
Hey,
As part of Google Summer of Code, together with two other students and
our mentors, I'm looking into supporting non-ebuild repository formats
in existing package managers. Currently, in Portage these are
supported by externally generating ebuilds from available metadata in
advance, and then using these in Portage by putting them in a local
overlay (see g-cpan for an example). In Paludis, there is some
"native" support for non-ebuild repository types (they have exheres,
just for starters), and I've been told it's fairly trivial to add new
repository types in Pkgcore, too, simply by inheriting from a base
class.
My point is of course not to bash on Portage, but to come up with an
elegant solution to support a list of new repository types.
Personally, Google is about to pay me for adding support for R package
repositories (CRAN and Bioconductor), and the two other students will
be doing Pypi and PEAR support, respectively. We aren't looking
forward to doing one task nine times: support for package managers.
See, our projects communicate with two others: on one side, we have to
read and interpret package repositories, on the other side, we need to
communicate with all the different package managers. Reading
repositories is something we'll only have to implement once for a
given repository format, but passing the relevant data to portage,
pkgcore or paludis is something less trivial.
We, students and mentors, have thought of various plans to only have
to write repository "plugins" and tackle the package manager side
together once and for all, but we couldn't reach agreement. How can we
support the three existing package managers, and any future package
manager which only supports PMS? To accomplish PMS-only package
manager support, the repository code would at least have to be able to
generate ebuilds, but perhaps we could come up with something better
than simply translating one type of metadata into the other, for
slightly more advanced package managers? Could we perhaps come up with
a *standard* for non-ebuild repository type /definitions/? Ideally,
developers would only have to write one chunk of code to read a
repository format, and then all package managers would be able to read
repositories of that type.
Now, before we roll in the discussion of stability: yes, blindly
importing packages from upstream is dangerous, and yes, it may just
set your cat on fire. However, it's a matter of fact that the package
maintainers simply don't have the time to manually check all packages,
and isn't Gentoo all /about/ at least having /access/ to those nuclear
plants? If this monster turns out to be deadly, we can always disable
support by default. That said, I do believe many packages, especially
in CRAN and Bioconductor, eventually will not do much more harm than
cause inflation of the U.S. dollar, which honestly cannot be helped
anyway. Wait, did I say Bioconductor? Oh, then terrorists with access
to Gentoo may have less trouble developing their own biological
weapons, but so be it, as long as they publish their DNA code as
GPL...
The final questions I'm really here for, then, are: how do you feel
about standardizing repository format definitions, how should we
support new repository types in current package managers, how should
we go about constructing a common interface for new format definitions
and why is it always on days like these I run out of coffee?
Thanks for all your thoughts!
Auke Booij / tulcod.