Re: [gentoo-dev] EAPI 3 PMS Draft
> On Tue, 17 Mar 2009, Tiziano Müller wrote:
> You forgot to mentioned that we probably also want that
> default_src_configure/src_compile die when they try to `cd` to an
> invalid ${S}.
Sorry, seems that I've missed the discussion on this one.
There is no 'cd "${S}"' command in the default functions. It's not
needed since they already start with S as their initial working
directory. If S doesn't point to an existing directory, WORKDIR is
used instead.
I hope you don't propose to remove this useful fallback behaviour in
general?
Ulrich
Re: [gentoo-dev] Re: EAPI 3 PMS Draft
Ryan Hill wrote: On Tue, 17 Mar 2009 00:22:36 +0100 Tiziano Müller wrote: * Am I to take it src_test is to remain in its current worthless state? Yes, I'd like to see it enable by default as well, but we have to discuss that further. So, not suited for a fast eapi release. Please fix all 'pkg fails tests' bugs in bugzilla first. And the fact some testsuites in system and commonly used libs take from 10x to 100x the buildtime to run. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] EAPI 3 PMS Draft
On Tue, Mar 17, 2009 at 6:16 AM, Thomas Anderson wrote: > While I'm sure there will be arguments for and against this, their merit > really does not matter. What matters is that this is completely offtopic > for the question of what should be in EAPI 3, and those feature's > specification. Please please do not associate the two as it'll just > prolong the acceptance of EAPI 3, and we all know we don't want that. > ++ discussions about this are best left for other threads, and (all the better) other times. -- ~Nirbheek Chauhan
[gentoo-dev] Re: EAPI 3 PMS Draft
On Mon, 16 Mar 2009 23:54:02 + Ciaran McCreesh wrote: > On Mon, 16 Mar 2009 17:51:00 -0600 > Ryan Hill wrote: > > On Tue, 17 Mar 2009 00:22:36 +0100 > > Tiziano Müller wrote: > > > > * Am I to take it src_test is to remain in its current worthless > > > > state? > > > Yes, I'd like to see it enable by default as well, but we have to > > > discuss that further. So, not suited for a fast eapi release. > > > > Please fix all 'pkg fails tests' bugs in bugzilla first. > > The nice thing about doing it on an EAPI bump is that it's > incremental. As people move towards EAPI 3, they'll all get caught > and fixed. Actually, that's a very good point. > With the current situation, src_test is worthless because a failure > doesn't mean there's a problem worth investigating. But if EAPI 3 > starts making src_test "run unless explicitly RESTRICTed or disabled", > any src_test failure in an EAPI 3 package will tell people something > requires attention. Whether it's enabled for EAPI 3 or not, I'd at least like to see 'test' added to FEATURES in targets/developer/make.defaults now. That should (hopefully) raise the visibility somewhat. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] timezone and other moving rc variables.
On Mon, Mar 16, 2009 at 2:46 AM, Ben de Groot wrote: > As per http://www.gentoo.org/doc/en/openrc-migration.xml under the > "Clock" heading. I know, reading documentation is an acquired taste... ;-) I've never seen this documentation before, didn't know it existed. maybe things like the timezone-data ebuild could refer to it in the 'info' message (the kernel used to do this with the kernel migration guide) -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] EAPI 3 PMS Draft
On Mon, Mar 16, 2009 at 11:59:45PM +0100, Maciej Mrozowski wrote: > On Monday 16 of March 2009 21:47:17 Ciaran McCreesh wrote: > > I've got a very rough draft of what EAPI 3 might end up looking like, > > based upon discussion: > [cut] > > Nice work. > To avoid further confusion I'd suggest removing all traces of kdebuild- > format > and its features (like PDEPEND labels, ranged dependencies) from PMS > document, > especially its references to Gentoo KDE project. > It has not been accepted thus should not exist in "Gentoo PMS" document. While I'm sure there will be arguments for and against this, their merit really does not matter. What matters is that this is completely offtopic for the question of what should be in EAPI 3, and those feature's specification. Please please do not associate the two as it'll just prolong the acceptance of EAPI 3, and we all know we don't want that. Regards, Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council -
Re: [gentoo-dev] EAPI 3 PMS Draft
On Mon, 16 Mar 2009 23:05:07 -0100 "Jorge Manuel B. S. Vicetto" wrote: > the point about kdebuild-1 and PMS was settled by the previous council > who decided that it wasn't and would never be part of the Gentoo PMS > and asked you to remove it from the document. Hence the "remove kdebuild" switch you can turn on if you're looking to use PMS for 'official' purposes rather than package manager development. > About it being approved by the Gentoo KDE team, that's not entirely > true. Most of the members of the team at the time worked on it and > opted to use it, but there was never a vote to approve it officially. The Gentoo KDE team lead at the time approved it and recognised it as official. > I don't have a problem with the kdebuild-1 EAPI, but it should be clear > that it was never an official Gentoo EAPI. It was officially approved by the Gentoo KDE team lead on behalf of his team. > It should also be cleared that although it was the chosen EAPI for the > KDE team 18 months ago, it is no longer used by the current team. So? I'd hope people aren't using EAPI 0 for anything new now either. > I suggest we create an Appendix with non-official EAPIs and > non-approved proposals. That way, kdebuild-1 and other EAPIs would be > listed in the Appendix, so we could have a list of features or > proposed features, and it would also be clear they're not official > EAPIs. What do you think? It doesn't work. There's no sensible way of separating out technical details of EAPIs into an appendix whilst keeping things readable. A summary as an appendix with references to the detailed section does work, and that's there already, as is a description of kdebuild-1's status. Also, this has nothing to do with EAPI 3. Please stop flogging this dead horse so that the noise doesn't drown out what we're trying to get done here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 PMS Draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Tue, 17 Mar 2009 00:26:36 +0100 > Tomáš Chvátal wrote: >>> Why? It was an official EAPI agreed upon by the Gentoo KDE project. >>> Having it there is helpful for package manager people, and removing >>> it would just mean more work when features make their way into >>> Portage. Besides, if you really don't want to see it, you can just >>> make it all invisible with one easy switch. >>> >> Actualy now people expect kde team to manage support for kdebuild >> too. So it is not such crazy request. > > There's a lot of kdebuild-1 stuff still out there that the Gentoo KDE > team created, and that users used because it was the best option at > the time. You can't pretend it never existed. And remember, a package > manager can't correctly uninstall something unless it knows about the > installed package's EAPI. > >>> We've been over all this before. Unless you have something new to >>> add, kindly avoid wasting people's time. >> And you are not wasting others time by flaming all around glep 54. I >> dont mean i dont agree with the glep i just dont agree with your way >> promoting it. And if you say i dont have to read all the long flame >> around you dont have the right saying somebody else not to write his >> ideas on this mailing list. > > There has yet to be a decent technical objection to kdebuild-1 > being in PMS. There has yet to be a decent technical objection to GLEP > 54. Anyone going around objecting to either without bringing new > material to the table is either trolling or hasn't done their homework. Ciaran, the point about kdebuild-1 and PMS was settled by the previous council who decided that it wasn't and would never be part of the Gentoo PMS and asked you to remove it from the document. Some people have argued about removing that EAPI from your document, but in my view they're wasting time as it simply is not part of the official Gentoo PMS currently. About it being approved by the Gentoo KDE team, that's not entirely true. Most of the members of the team at the time worked on it and opted to use it, but there was never a vote to approve it officially. I have no problem with the overlay still using it and will try to ensure that we don't break it. However, like the members of the KDE team at the time opted to use the kdebuild-1 EAPI, the current members have opted to use EAPI-2 and don't support kdebuild-1 themselves. As the only PM that ever supported kdebuild-1 is paludis, the backwards compatibility issue is not as relevant as no one is asking you to drop the kdebuild-1 support from paludis and portage and pkgcore can keep ignoring those ebuilds. I don't have a problem with the kdebuild-1 EAPI, but it should be clear that it was never an official Gentoo EAPI. It should also be cleared that although it was the chosen EAPI for the KDE team 18 months ago, it is no longer used by the current team. There was a time for it and it opened the road for some very useful features that have already been delivered in EAPI-2 or that are being discussed for future EAPIs. As such, I propose a different approach for this issue. I suggest we create an Appendix with non-official EAPIs and non-approved proposals. That way, kdebuild-1 and other EAPIs would be listed in the Appendix, so we could have a list of features or proposed features, and it would also be clear they're not official EAPIs. What do you think? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm+6TMACgkQcAWygvVEyAIF6ACgkox34uc08LHpLjW+iSRmCGJe 9MQAn0g0AaOiq1C9pfRcfCTYhyhYb0+D =g6se -END PGP SIGNATURE-
Re: [gentoo-dev] Re: EAPI 3 PMS Draft
On Mon, 16 Mar 2009 17:51:00 -0600 Ryan Hill wrote: > On Tue, 17 Mar 2009 00:22:36 +0100 > Tiziano Müller wrote: > > > * Am I to take it src_test is to remain in its current worthless > > > state? > > Yes, I'd like to see it enable by default as well, but we have to > > discuss that further. So, not suited for a fast eapi release. > > Please fix all 'pkg fails tests' bugs in bugzilla first. The nice thing about doing it on an EAPI bump is that it's incremental. As people move towards EAPI 3, they'll all get caught and fixed. With the current situation, src_test is worthless because a failure doesn't mean there's a problem worth investigating. But if EAPI 3 starts making src_test "run unless explicitly RESTRICTed or disabled", any src_test failure in an EAPI 3 package will tell people something requires attention. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI 3 PMS Draft
On Tue, 17 Mar 2009 00:22:36 +0100 Tiziano Müller wrote: > > * Am I to take it src_test is to remain in its current worthless > > state? > Yes, I'd like to see it enable by default as well, but we have to > discuss that further. So, not suited for a fast eapi release. Please fix all 'pkg fails tests' bugs in bugzilla first. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Maintainence of /usr/portage/skel.* and some updates for skel.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marijn Schouten (hkBst) wrote:
> Thomas Sachau wrote:
>> Petteri Räty schrieb:
>>> Thomas Sachau wrote:
I would like to know, if there is some policy about editing skel.* files
or who owns/maintains them.
Additionally, i suggest some changes to skel.ebuild:
>>> Posts diffs to gentoo-dev and if there are no objections --> commit.
>>>
>>> Regards,
>>> Petteri
>>>
>> ok, here my proposed diff for skel.ebuild
>
>
> # Run-time dependencies. Must be defined to whatever this depends on to run.
> # The below is valid if the same run-time depends are required to compile.
> -RDEPEND="${DEPEND}"
> +# You only need to define this, if you have run-time dependencies or dont
> have
> +# run-time dependencies, but compile time dependencies set in DEPEND (in this
> +# case, it should be RDEPEND="").
> +#RDEPEND="${DEPEND}"
>
> Why not make it simple and require RDEPEND to be defined?
>
> Marijn
>
Well, the current proposal for EAPI-3 includes killing the
RDEPEND=${DEPEND} default behaviour, so this section should be left
alone, imo.
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm+4p0ACgkQcAWygvVEyALXcACgmsLk9yme1GI+XUoJTUGVy3H0
ssIAoJQ7Mml3VvNBSOktrU+x7XyzPDNh
=lJ9G
-END PGP SIGNATURE-
Re: [gentoo-dev] EAPI 3 PMS Draft
On Tue, 17 Mar 2009 00:26:36 +0100 Tomáš Chvátal wrote: > > Why? It was an official EAPI agreed upon by the Gentoo KDE project. > > Having it there is helpful for package manager people, and removing > > it would just mean more work when features make their way into > > Portage. Besides, if you really don't want to see it, you can just > > make it all invisible with one easy switch. > > > Actualy now people expect kde team to manage support for kdebuild > too. So it is not such crazy request. There's a lot of kdebuild-1 stuff still out there that the Gentoo KDE team created, and that users used because it was the best option at the time. You can't pretend it never existed. And remember, a package manager can't correctly uninstall something unless it knows about the installed package's EAPI. > > We've been over all this before. Unless you have something new to > > add, kindly avoid wasting people's time. > > And you are not wasting others time by flaming all around glep 54. I > dont mean i dont agree with the glep i just dont agree with your way > promoting it. And if you say i dont have to read all the long flame > around you dont have the right saying somebody else not to write his > ideas on this mailing list. There has yet to be a decent technical objection to kdebuild-1 being in PMS. There has yet to be a decent technical objection to GLEP 54. Anyone going around objecting to either without bringing new material to the table is either trolling or hasn't done their homework. The nature of Gentoo management is such that any unanswered objection is treated as legitimate grounds to stall a proposal indefinitely, even if that objection has been answered ten times previously. I really don't want to see the Council sit around and not approve EAPI 3 until we have the whole kdebuild discussion again. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 PMS Draft
Dne úterý 17 Březen 2009 00:20:11 Ciaran McCreesh napsal(a): > On Mon, 16 Mar 2009 23:59:45 +0100 > > Maciej Mrozowski wrote: > > To avoid further confusion I'd suggest removing all traces of > > kdebuild- format and its features (like PDEPEND labels, ranged > > dependencies) from PMS document, especially its references to Gentoo > > KDE project. It has not been accepted thus should not exist in > > "Gentoo PMS" document. > > Why? It was an official EAPI agreed upon by the Gentoo KDE project. > Having it there is helpful for package manager people, and removing it > would just mean more work when features make their way into Portage. > Besides, if you really don't want to see it, you can just make it all > invisible with one easy switch. > Actualy now people expect kde team to manage support for kdebuild too. So it is not such crazy request. > We've been over all this before. Unless you have something new to add, > kindly avoid wasting people's time. And you are not wasting others time by flaming all around glep 54. I dont mean i dont agree with the glep i just dont agree with your way promoting it. And if you say i dont have to read all the long flame around you dont have the right saying somebody else not to write his ideas on this mailing list. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 PMS Draft
Thanks a lot for your work.
Am Montag, den 16.03.2009, 20:47 + schrieb Ciaran McCreesh:
> I've got a very rough draft of what EAPI 3 might end up looking like,
> based upon discussion:
>
> http://github.com/ciaranm/pms/tree/eapi-3
>
> Note that I will probably rebase and modifying the branch quite a bit,
> so if you don't know how to deal with that when using git, don't track
> it.
>
> It should be one commit per feature, which makes it fairly easy to
> remove anything that ends up not making it, and very easy to see what's
> proposed, which currently looks like this:
>
> * Introduce eapi 3
> * Rework tables for EAPI 3.
> * EAPI 3 has pkg_pretend.
> * EAPI 3 supports slot operator dependencies
> * EAPI 3 has use dependency defaults
> * PROPERTIES, DEFINED_PHASES mandatory in EAPI 3
> * EAPI 3 has a default src_install
> * EAPI 3 has controllable compression and docompress
> * EAPI 3 has dodoc -r
> * EAPI 3 requires doins support for symlinks
> * EAPI 3 bans || ( use? ( ... ) )
> * dohard and dosed banned in EAPI 3
> * doinclude, newinclude for EAPI 3
> * EAPI 3 supports .xz, .tar.xz
> * EAPI 3 has more econf arguments
> * EAPI 3 supports pkg_info on installed packages
> * USE is stricter in EAPI 3
> * Note that (+) won't work on USE_EXPAND etc things
> * AA, KV gone in EAPI 3
>
> Still to work out:
>
> * The exact details for the new USE restrictions. In particular, do we
> want IUSE_IMPLICIT? We'll also need an accurate list of all
> possible values for things like LINGUAS.
>
> * The [use(+)] thing. For various really pesky reasons, there's no way
> things like [video_cards_radeon(+)] can be expected to work when
> applied against EAPIs before 3, but it can be made to work if we know
> it'll only ever be applied against things with EAPI 3 or later. Is it
> easier to just say it's never allowed, though?
>
> * What's a doexample?
>
> * What's default_src_install going to do? I've seen a load of
> variations. It looks like our choices are between things that ignore
> docs, making it largely worthless, or things that use a DOCS
> variable, which Donnie hates (despite making extensive use of such
> things himself in eclasses).
Well, we have distutils and gnome2 eclass using DOCS (to name a few,
short glep shows around 18 eclasses), so I'd say: if we go for a
default_src_install it needs surely DOCS.
If default_src_install should install some DOCS automatically, I'd like
to have a way to disable that behaviour without having to roll my own
src_install.
You forgot to mentioned that we probably also want that
default_src_configure/src_compile die when they try to `cd` to an
invalid ${S}.
>
> * "Provide ebuilds a way to differentiate between updates and
> removals". I suggested REPLACING_VERSIONS and REPLACED_BY_VERSION,
> but I've not had any feedback on that.
>
> * "Utility commands, even the ones that aren't functions, should die.".
> Is Portage likely to be able to do this in the timeframe we're after?
I'd say this is a pretty isolated task even people without in-depth
portage knowledge can work on, so I guess it can be implemented.
>
> * "Calling unpack on an unrecognised extension should be fatal, unless
> --if-compressed is specified.". There've been questions on this, but
> no obvious outrage. Is this in or out?
I'd vote for "in" here since I prefer defined behaviour over undefined
and people who want unpack to unpack not-packed files should state it
explicitly.
>
> * I've left out killing off dohtml. Was a decision reached on that?
No.
>
> * RDEPEND=DEPEND is still in. Again, was a decision reached?
No, but since repoman is already warning when no RDEPEND or DEPEND is
specified I guess most people want it to be explicit.
>
> * xz is in, but do we really want to do that when there appears to be
> nothing stable that can deal with xz? lzma going in was a mistake
> caused by people being too eager here in exactly the same way they
> were for making Portage handle xz...
>
> * Am I to take it src_test is to remain in its current worthless state?
Yes, I'd like to see it enable by default as well, but we have to
discuss that further. So, not suited for a fast eapi release.
Btw, I put up a document explaining the changes in some detail here:
http://dev.gentoo.org/~dev-zero/docs/EAPI3.{rst,html}
(including references to bugs if any, etc.)
It is completely based on the spreadsheet we used earlier for
discussion. I'll finish it within the next days.
Cheers,
Tiziano
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI 3 PMS Draft
On Mon, 16 Mar 2009 23:59:45 +0100 Maciej Mrozowski wrote: > To avoid further confusion I'd suggest removing all traces of > kdebuild- format and its features (like PDEPEND labels, ranged > dependencies) from PMS document, especially its references to Gentoo > KDE project. It has not been accepted thus should not exist in > "Gentoo PMS" document. Why? It was an official EAPI agreed upon by the Gentoo KDE project. Having it there is helpful for package manager people, and removing it would just mean more work when features make their way into Portage. Besides, if you really don't want to see it, you can just make it all invisible with one easy switch. We've been over all this before. Unless you have something new to add, kindly avoid wasting people's time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 PMS Draft
Le 16/03/2009 23:59, Maciej Mrozowski a écrit : * RDEPEND=DEPEND is still in. Again, was a decision reached? Imho it would be about time to kill implicit build time dependency assignment. +1, let's rip it out. Rémi
Re: [gentoo-dev] EAPI 3 PMS Draft
On Monday 16 of March 2009 21:47:17 Ciaran McCreesh wrote: > I've got a very rough draft of what EAPI 3 might end up looking like, > based upon discussion: [cut] Nice work. To avoid further confusion I'd suggest removing all traces of kdebuild- format and its features (like PDEPEND labels, ranged dependencies) from PMS document, especially its references to Gentoo KDE project. It has not been accepted thus should not exist in "Gentoo PMS" document. > * RDEPEND=DEPEND is still in. Again, was a decision reached? Imho it would be about time to kill implicit build time dependency assignment. -- regards MM -- Udar sloneczny prezesa Kaczynskiego... >>> http://link.interia.pl/f2083
Re: [gentoo-dev] Maintainence of /usr/portage/skel.* and some updates for skel.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Sachau wrote:
> Petteri Räty schrieb:
>> Thomas Sachau wrote:
>>> I would like to know, if there is some policy about editing skel.* files or
>>> who owns/maintains them.
>>> Additionally, i suggest some changes to skel.ebuild:
>>>
>> Posts diffs to gentoo-dev and if there are no objections --> commit.
>>
>> Regards,
>> Petteri
>>
>
> ok, here my proposed diff for skel.ebuild
>
>
# Run-time dependencies. Must be defined to whatever this depends on to run.
# The below is valid if the same run-time depends are required to compile.
- -RDEPEND="${DEPEND}"
+# You only need to define this, if you have run-time dependencies or dont have
+# run-time dependencies, but compile time dependencies set in DEPEND (in this
+# case, it should be RDEPEND="").
+#RDEPEND="${DEPEND}"
Why not make it simple and require RDEPEND to be defined?
Marijn
- --
Gods do not want you to think, lest they lose existence.
Religions do not want you to think, lest they lose power.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
[gentoo-dev] EAPI 3 PMS Draft
I've got a very rough draft of what EAPI 3 might end up looking like, based upon discussion: http://github.com/ciaranm/pms/tree/eapi-3 Note that I will probably rebase and modifying the branch quite a bit, so if you don't know how to deal with that when using git, don't track it. It should be one commit per feature, which makes it fairly easy to remove anything that ends up not making it, and very easy to see what's proposed, which currently looks like this: * Introduce eapi 3 * Rework tables for EAPI 3. * EAPI 3 has pkg_pretend. * EAPI 3 supports slot operator dependencies * EAPI 3 has use dependency defaults * PROPERTIES, DEFINED_PHASES mandatory in EAPI 3 * EAPI 3 has a default src_install * EAPI 3 has controllable compression and docompress * EAPI 3 has dodoc -r * EAPI 3 requires doins support for symlinks * EAPI 3 bans || ( use? ( ... ) ) * dohard and dosed banned in EAPI 3 * doinclude, newinclude for EAPI 3 * EAPI 3 supports .xz, .tar.xz * EAPI 3 has more econf arguments * EAPI 3 supports pkg_info on installed packages * USE is stricter in EAPI 3 * Note that (+) won't work on USE_EXPAND etc things * AA, KV gone in EAPI 3 Still to work out: * The exact details for the new USE restrictions. In particular, do we want IUSE_IMPLICIT? We'll also need an accurate list of all possible values for things like LINGUAS. * The [use(+)] thing. For various really pesky reasons, there's no way things like [video_cards_radeon(+)] can be expected to work when applied against EAPIs before 3, but it can be made to work if we know it'll only ever be applied against things with EAPI 3 or later. Is it easier to just say it's never allowed, though? * What's a doexample? * What's default_src_install going to do? I've seen a load of variations. It looks like our choices are between things that ignore docs, making it largely worthless, or things that use a DOCS variable, which Donnie hates (despite making extensive use of such things himself in eclasses). * "Provide ebuilds a way to differentiate between updates and removals". I suggested REPLACING_VERSIONS and REPLACED_BY_VERSION, but I've not had any feedback on that. * "Utility commands, even the ones that aren't functions, should die.". Is Portage likely to be able to do this in the timeframe we're after? * "Calling unpack on an unrecognised extension should be fatal, unless --if-compressed is specified.". There've been questions on this, but no obvious outrage. Is this in or out? * I've left out killing off dohtml. Was a decision reached on that? * RDEPEND=DEPEND is still in. Again, was a decision reached? * xz is in, but do we really want to do that when there appears to be nothing stable that can deal with xz? lzma going in was a mistake caused by people being too eager here in exactly the same way they were for making Portage handle xz... * Am I to take it src_test is to remain in its current worthless state? I've probably missed some more things, but I don't know what they are, so if anyone can find any please list them. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Maintainence of /usr/portage/skel.* and some updates for skel.ebuild
Petteri Räty schrieb:
> Thomas Sachau wrote:
>> I would like to know, if there is some policy about editing skel.* files or
>> who owns/maintains them.
>> Additionally, i suggest some changes to skel.ebuild:
>>
>
> Posts diffs to gentoo-dev and if there are no objections --> commit.
>
> Regards,
> Petteri
>
ok, here my proposed diff for skel.ebuild
--
Thomas Sachau
Gentoo Linux Developer
--- skel.ebuild 2009-03-16 17:50:59.0 +0100
+++ skel.ebuild.new 2009-03-16 18:01:36.0 +0100
@@ -21,14 +21,14 @@
# inherit lists eclasses to inherit functions from. Almost all ebuilds should
# inherit eutils, as a large amount of important functionality has been
-# moved there. For example, the $(get_libdir) mentioned below wont work
+# moved there. For example, the epatch call mentioned below wont work
# without the following line:
inherit eutils
# A well-used example of an eclass function that needs eutils is epatch. If
# your source needs patches applied, it's suggested to put your patch in the
# 'files' directory and use:
#
-# epatch ${FILESDIR}/patch-name-here
+# epatch "${FILESDIR}"/patch-name-here
#
# eclasses tend to list descriptions of how to use their functions properly.
# take a look at /usr/portage/eclasses/ for more examples.
@@ -96,11 +96,14 @@
# had installed on your system when you tested the package. Then
# other users hopefully won't be caught without the right version of
# a dependency.
-DEPEND=""
+#DEPEND=""
# Run-time dependencies. Must be defined to whatever this depends on to run.
# The below is valid if the same run-time depends are required to compile.
-RDEPEND="${DEPEND}"
+# You only need to define this, if you have run-time dependencies or dont have
+# run-time dependencies, but compile time dependencies set in DEPEND (in this
+# case, it should be RDEPEND="").
+#RDEPEND="${DEPEND}"
# Source directory; the dir where the sources can be found (automatically
# unpacked) inside ${WORKDIR}. The default value for S is ${WORKDIR}/${P}
@@ -108,10 +111,13 @@
# to keep it tidy.
#S="${WORKDIR}/${P}"
-src_compile() {
+
+# The following src_compile function is implemented as default by portage, so
+# you only need to call it, if you need a different behaviour.
+#src_compile() {
# Most open-source packages use GNU autoconf for configuration.
- # The quickest (and preferred) way of running configure is:
- econf || die "econf failed"
+ # The default, quickest (and preferred) way of running configure is:
+ #econf
#
# You could use something similar to the following lines to
# configure your package before compilation. The "|| die" portion
@@ -135,8 +141,9 @@
# related to parallelism, in these cases, use emake -j1 to limit
# make to a single process. The -j1 is a visual clue to others
# that the makefiles have bugs that have been worked around.
- emake || die "emake failed"
-}
+
+ #emake || die "emake failed"
+#}
src_install() {
# You must *personally verify* that this trick doesn't install
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] gentoo KVM images now available :)
On Fri, Mar 13, 2009 at 6:53 AM, wrote: Hi, I already posted some initial images on tinderbox. http://tinderbox.dev.gentoo.org/virtualization/amd64/ Some weeks old by now. But I am fairly confident that image building can be made automatic via scripting. Granted, I did not make an announcement of my latest images just the old ones[1], it is just a pet project for me in its current state. It is extremely easy to make a new image for others with the weekly automated builds now. -Jeremy [1]: http://blog.jolexa.net/2008/11/14/on-virtualization/
