[Catalog-sig] PyCon sprint for PEPs 314 and 243?
jafo at tummy.com
Mon Jan 17 01:17:18 CET 2005
On Sat, Jan 15, 2005 at 07:53:51PM -0500, Bob Ippolito wrote:
>Is the RPM format itself well specified?
Yes. At it's heart it's just a cpio archive with some extra information.
>Is there already a suitably
>licensed pure Python implementation for creating and using RPM files?
Doubtful. However, it's still valuable to use a mature package format,
despite lack of existing code, as it prevents you from having to design and
build a new format. .deb and .rpm have years of experience under their
belts, including ability to be relocated, tools to build and manipulate
them, signatures in the case of .rpm, dependencies, etc... I'd recommend
.rpms primarily because they have the ability to be signed.
>Platforms that don't already have RPM are going to need it, and I
>believe that librpm is GPL (and probably also not portable everywhere
>Python is), so we couldn't add that dependency for an extension to wrap
Personally, I wouldn't use a system that didn't integrate with my system
package format. Instead I'd prefer "python setup.py bdist_rpm" or
bdist_deb. That's why I was always more interested in solving the problem
of distributing these packages as opposed to building a new package format.
The process of building the catalot system seems to get mired down in
issues like handling all platforms and allowing non-root users to install
packages outside of the system package location.
>Dependency tracking and resolution requires package maintainers.
I don't see how having dependencies requires that much more than the
maintenance for a setup.py. In the worst case, it doesn't hurt anything to
have dependencies that nobody uses. If we already have a package database,
then we already know if "optik" is installed, for example, so having a
package say that it requires "optik" isn't a huge deal.
>From a user perspective, lacking dependencies is a huge problem. When you
want to install one package which requires another, it's far better if the
system can determine this and pull in the required other packages. If
you'd like an example of just how big a deal users consider this, look at
pretty much any discussion related to RPMs and "dependency hell". These
are almost always discussions from people using "rpm" directly to install
packages (which at least alerts on dependencies, but doesn't automatically
install dependencies). Any discussion mentioning that Debian packages are
better than RPMs is also likely about this, because "apt-get" (a layer on
top of "dpkg") follows and downloads dependencies where "dpkg" and
"rpm" do not.
>I think we'd be better off deferring the implementation of this, because
>it would take more effort to get this solution out the door and it
>would require an additional burden to make these packages.
It wouldn't *REQUIRE* the burden, because you can always release packages
that simply do not list their dependencies.
>If PyPI had
>tried to solve packaging, distribution, dependency tracking, etc. from
>the start, it would've never finished.
That's certainly not true, as proof of it I submit "yum" which does solve
all these problems, using Python, and *HAS* made progress to a usable
state. I know something of what I speak about here, since I took the
system which I demonstrated at Python 9 in 2001, tweeked it a bit over the
next month, and turned it into a system for Red Hat package dependency
tracking, installation, and downloading, which worked extremely well for
The difficulty with applying this solution to Python was entirely
political, not at all technical. It boiled down to this: in order to reach
critical mass, I was certain that we needed an easy way for module
packagers to submit their packages up to a central repository. After the
Catalog-SIG discussion at Python 9, I built a patch to Distutils which
would do exactly this. Getting that code incorporated into the upcoming
Python release was the problem.
>I also find the Red Hat / Debian solution to *this* issue quite
>obnoxious in that you often have to install or upgrade more packages
>than should be necessary.
Admittedly, I've only been using the above packaging systems for
a decade, but in my experience that is absolutely not true. If an update
to a package says that it needs Python >= 2.3.4 instead of Python >= 2.3,
then it probably *DOES* need those other packages upgraded. If it is
making unnecessary demands on other packages, then it should be reported to
the packager as a bug, because that's what it is.
If you don't believe it's correct before you start testing, what
could possibly convince you? -- Don Grimes, 1994
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin
More information about the Catalog-sig