On Mon, Dec 18, 2006 at 12:33:19PM -0800, Toshio Kuratomi wrote:
On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote:
> On Mon, Dec 18, 2006 at 07:23:29PM +0100, Axel Thimm wrote:
> > On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote:
> > > The crucial issue are the dependencies that right now have to stay
> > > within each packaging format; if rpm's can't contain any egg (or
gem or
> > > whatnot) info, users will end up installing the same package twice, just
> > > to fulfill dependencies completely within each packaging system.
> >
> > Don't you have the same issue if you install the egg with -Z? If not,
> > then the (egg-)package dependencies are obvioulsy spooled somewhere on
> > disk for easy_install and friends to find.
>
> Looks like all has been considered in advance by the egg folks:
>
> > --single-version-externally-managed
> > This boolean option tells the install command to perform an "old
> > style" installation, with the addition of an .egg-info directory
> > so that the installed project will still have its metadata
> > available and operate normally. If you use this option, you must
> > also specify the --root or --record options (or both), because
> > otherwise you will have no way to identify and remove the
> > installed files.
>
> > > It would be much more userfriendly if we laid the groundwork for other
> > > packaging systems to depend on rpm-installed bits; that mostly means to
> > > _allow_ inclusion of non-rpm packaging metadata in rpms.
> >
> > If you like so, having "egg-provides" is fine, of course. Just like
we
> > have foo.pc, but don't keep the full tarball around.
>
> The equivalent to *.pc files seem to be the .egg-info subdirs. So we
> don't need to ship the egg file in addition within the rpm file, but
> still feed the egg packaging system with information.
Heh. This is what we've been doing :-)
Then why are we trying to change that?
From lmacken's TurboMail spec, for instance:
%files
%defattr(-,root,root,-)
%{python_sitelib}/TurboMail-%{version}-py%{pyver}.egg-info
--
Axel.Thimm at
ATrpms.net