Joshua,
I know that draft quite well, I used as reference for writing Entropy,
our binary package manager which only uses {R,P}DEPEND and not DEPEND.
So here comes the issue, when *DEPEND are not declared properly
Entropy pulls in unneeded packaged.
What you are saying is something I am already aware of :) zmedico has
been really helpful :)
On 3/14/08, joshua jackson <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Fabio Erculiani wrote:
>
> | Hi Joshua,
> | I never had issues with my emails. So I don't really know what to
> | answer you regarding to your issues :)
> | SPLIT: Although I think it can be a suboptimal thing for us, I can
> | understand your policy. Let me add that, to me, the biggest issue is
> | about (R)DEPEND. Splitting packages and maintaining in an overlay it's
> | not that hard.
> |
> |
> |
>
> I personally have no desire to follow the redhat/debian/other binary
> packaging systems which split up infinitesimally small packages. It
> causes a lot more busywork in my opinion then any potential benefits
> that it gains you.
>
> As far as the depend issue you mentioned: Having both Rdepends and
> Depends isn't as far as I'm aware part of any EAPI currently (Correct me
> if I'm wrong people). Rdepends are needed for the builds so you will
> often see either RDEPENDS=${DEPEND} or vice versa. If its not there then
> its more of a matter of accounting then anything. I would think, and
> correct me if I'm wrong again, that it would make sense that if you only
> have RDEPENDS or DEPEND, then those same applications are required in
> the runtime of the application. Does it need to be explicitly stated? So
> far the three package manager that I'm aware of all manage this fine.
> Those being portage, paludis, and pkgcore. If there are other package
> managers out there that might have issues Its a perfect example of a
> reason to be involved in the EAPI discussions to help define what is
> needed and where.
>
> So what I suggest to you is perhaps looking over the EAPI=0 draft
> documentation and proposing some additions and or modifications that
> benefit everyone (not just one person), as its designed to be a standard
> for anyone who makes use of ebuilds and beyond.
>
> http://dev.gentoo.org/~spb/pms.pdf
>
> Is the current form, but halcy0n is working on an updated version of it
> for the next council meeting.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>
> iD8DBQFH2bL22ZWR0Jhg/EsRAkduAJsGBKKl5HgR5YXziPn9yOLbi5F5MwCfacIC
> b/aqsokP3A6JFJ7hO4LGNXY=
> =BGqi
>
> -----END PGP SIGNATURE-----
> --
> gentoo-dev@lists.gentoo.org mailing list
>
>
--
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
--
gentoo-dev@lists.gentoo.org mailing list
