-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Fri, 13 Apr 2007 14:21:16 +0200 > Marius Mauch <[EMAIL PROTECTED]> wrote: >> On Wed, 11 Apr 2007 15:41:01 +0100 >> Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
>>> * Phase changes: src_fetch -> src_unpack -> src_prepare -> >>> src_configure -> src_compile -> src_test -> src_install >> No to src_fetch > > Why? It would be useful for CVS, SVN etc ebuilds. I'm not suggesting it > be used for SRC_URI things. Hi list, Not having src_fetch is really braindead. There are always gonna be silly packages that don't fit into the nice default SRC_URI scheme. Use case one: package is completely unversioned upstream. Have src_fetch add a version as appropriate to the downloaded/mirrored version. This will work as change of upstream sources will be detected by all the checksums we do. Use case two: package is incompatibly versioned. smlnj for example releases unversioned files in a versioned directory. There is currently no way to mirror that in distfiles as there is nowhere that I could specify that I want files to go to a separate directory. Right. These use cases are really a bonus. Having src_fetch that we can redefine is simply the right thing and I can't believe it doesn't exist already. Consider this my vote for an EAPI 2 which adds user-redefinable src_fetch ASAP. Marijn - -- Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML <http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNJvRp/VmCx0OL2wRAnc9AJ0bIm1snoGivLSZgTEE4dx7e2VgQwCeL7Kk fwvaBcfVHv+nSXQd1KTT3ls= =44uf -----END PGP SIGNATURE----- -- [EMAIL PROTECTED] mailing list
