On Sun, 16 Aug 2015 09:52:06 -0700
Raymond Jennings wrote:
> What's the best way to get rid of deprecated ebuilds?
>
> Do we just wait for their maintainers to migrate them or should they
> be sought out and flagged? I'm pondering searching for EAPI 0
> ebuilds and filing bug reports on them.
What's the best way to get rid of deprecated ebuilds?
Do we just wait for their maintainers to migrate them or should they be
sought out and flagged? I'm pondering searching for EAPI 0 ebuilds and
filing bug reports on them.
On Sun, Aug 16, 2015 at 6:57 AM, Rich Freeman wrote:
> On Sun, Aug 16
On Sun, Aug 16, 2015 at 9:47 AM, "Paweł Hajdan, Jr."
wrote:
> On 8/16/15 3:29 PM, Rich Freeman wrote:
>> They are deprecated already:
>> https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf
>>
>> Deprecated means stop adding them, and move away from them. Repoman
>> will give you a
On 8/16/15 3:29 PM, Rich Freeman wrote:
> They are deprecated already:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf
>
> Deprecated means stop adding them, and move away from them. Repoman
> will give you a warning about them.
Is anything blocking deprecating EAPI4 in the
On Sat, Aug 15, 2015 at 10:09 PM, Raymond Jennings wrote:
> On Fri, Aug 14, 2015 at 6:16 PM, Ian Stakenvicius wrote:
>>
>> Finally, the gentoo developer quiz -should- still contain questions
>> about ancient stuff. There are still EAPI0 and EAPI2 ebuilds in the
>> tree at least.
>
>
> Why not de
On Fri, Aug 14, 2015 at 6:16 PM, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 14/08/15 06:43 PM, Johannes Huber wrote:
> >
> >
> > Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
> >> Hi,
> >
> >> While I have no objections about EAPI 4 deprecation (except
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/08/15 02:48 AM, Andrew Savchenko wrote:
> On Sat, 15 Aug 2015 08:12:42 +0200 Paweł Hajdan, Jr. wrote:
>> On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
>>> Secondly, though, conversion to EAPI5 is not actually
>>> trivial, there are a couple of th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 08/15/15 um 07:35 schrieb Michał Górny:
>
> This is a cheap hack, not a conversion. Proper conversion to a new
> EAPI is about using the new EAPI features. Not marking it 'done',
> and pretending there's nothing more to do.
>
Yeah you are ri
Dnia 2015-08-15, o godz. 09:06:48
Ulrich Mueller napisał(a):
> > On Sat, 15 Aug 2015, Paweł Hajdan, wrote:
>
> > Nothing seems to prevent doing the mass conversion first,
> > deprecating EAPI 4, and then having a second, slower pass to make
> > sure the ebuilds are using EAPI 5 as they shoul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/14/2015 03:05 PM, Johannes Huber wrote:
> Hello Gentoos Penguins,
>
> if we want to attract more contributors we should consider to have
> one supported EAPI (latest). EAPI 4 is the last not marked as
> deprecated (< EAPI 5). The move in ebuil
> On Sat, 15 Aug 2015, Paweł Hajdan, wrote:
> Nothing seems to prevent doing the mass conversion first,
> deprecating EAPI 4, and then having a second, slower pass to make
> sure the ebuilds are using EAPI 5 as they should be. One way might
> be to add a "TODO" comment during mass conversion,
On Sat, 15 Aug 2015 08:12:42 +0200 Paweł Hajdan, Jr. wrote:
> On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
> > Secondly, though, conversion to EAPI5 is not actually trivial, there
> > are a couple of things, 'usex' related for instance, that also need
> > to be taken care of. If it was just a matte
On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
> Secondly, though, conversion to EAPI5 is not actually trivial, there
> are a couple of things, 'usex' related for instance, that also need
> to be taken care of. If it was just a matter of running a sed -e
> 's/^EAPI=4/EAPI=5/' on all in-tree ebuilds t
On 8/15/15 7:35 AM, Michał Górny wrote:
> Dnia 2015-08-15, o godz. 00:05:57
> Johannes Huber napisał(a):
>> if we want to attract more contributors we should consider to have one
>> supported EAPI (latest). EAPI 4 is the last not marked as deprecated
>> (< EAPI 5). The move in ebuilds from EAPI 4
Dnia 2015-08-15, o godz. 00:05:57
Johannes Huber napisał(a):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello Gentoos Penguins,
>
> if we want to attract more contributors we should consider to have one
> supported EAPI (latest). EAPI 4 is the last not marked as deprecated
> (< EAP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/08/15 06:43 PM, Johannes Huber wrote:
>
>
> Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
>> Hi,
>
>> While I have no objections about EAPI 4 deprecation (except
>> concerns mentioned above), I see no strong need for this also.
>> Just dec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
> Hi,
>
> While I have no objections about EAPI 4 deprecation (except
> concerns mentioned above), I see no strong need for this also. Just
> declare EAPI 5 as recommended. Having legacy support for
Hi,
On Sat, 15 Aug 2015 00:05:57 +0200 Johannes Huber wrote:
> if we want to attract more contributors we should consider to have one
> supported EAPI (latest). EAPI 4 is the last not marked as deprecated
> (< EAPI 5). The move in ebuilds from EAPI 4 to EAPI 5 is very simple
> replacing the declar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Gentoos Penguins,
if we want to attract more contributors we should consider to have one
supported EAPI (latest). EAPI 4 is the last not marked as deprecated
(< EAPI 5). The move in ebuilds from EAPI 4 to EAPI 5 is very simple
replacing the de
s/with/on/
--
Fabio Erculiani
On Sun, 2 Sep 2012 21:38:26 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
> wrote:
> > On Sun, 2 Sep 2012 20:46:19 +0200
> > Fabio Erculiani wrote:
> >> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
> >> wrote:
> >> > and we have worked out all the difficultie
On Sun, 2 Sep 2012 20:10:38 +0100
Ciaran McCreesh wrote:
> On Sun, 2 Sep 2012 21:07:30 +0200
> Michał Górny wrote:
> > On Sun, 2 Sep 2012 19:08:33 +0100
> > Ciaran McCreesh wrote:
> > > On Sun, 2 Sep 2012 17:23:40 +0200
> > > Michał Górny wrote:
> > > > An effective SDEPEND implementation is d
On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
wrote:
> On Sun, 2 Sep 2012 20:46:19 +0200
> Fabio Erculiani wrote:
>> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
>> wrote:
>> > and we have worked out all the difficulties.
>>
>> Please elaborate. What difficulties? What did you implement oth
On Sun, 2 Sep 2012 21:07:30 +0200
Michał Górny wrote:
> On Sun, 2 Sep 2012 19:08:33 +0100
> Ciaran McCreesh wrote:
> > On Sun, 2 Sep 2012 17:23:40 +0200
> > Michał Górny wrote:
> > > An effective SDEPEND implementation is definitely nowhere close
> > > to simple. Nor is presenting those dependen
On Sun, 2 Sep 2012 19:08:33 +0100
Ciaran McCreesh wrote:
> On Sun, 2 Sep 2012 17:23:40 +0200
> Michał Górny wrote:
> > An effective SDEPEND implementation is definitely nowhere close
> > to simple. Nor is presenting those dependencies to users.
>
> Indeed it's not, but we *do* have a reference
On Sun, 2 Sep 2012 20:46:19 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
> wrote:
> > and we have worked out all the difficulties.
>
> Please elaborate. What difficulties? What did you implement other than
> plain SDEPEND? With what features? Lots of detail miss
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
wrote:
> and we have worked out all the difficulties.
Please elaborate. What difficulties? What did you implement other than
plain SDEPEND? With what features? Lots of detail missing.
>
> Having said that, if we're going with suggested dependencies
On Sun, 2 Sep 2012 17:23:40 +0200
Michał Górny wrote:
> An effective SDEPEND implementation is definitely nowhere close
> to simple. Nor is presenting those dependencies to users.
Indeed it's not, but we *do* have a reference implementation and lots
of practical experience with it, and we have wo
On Sun, 2 Sep 2012 17:51:00 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny
> wrote:
> > On Sun, 2 Sep 2012 17:09:22 +0200
> > Fabio Erculiani wrote:
> >
> >> On Sun, Sep 2, 2012 at 4:57 PM, hasufell
> >> wrote:
> >> >
> >> >
> >> > Why not introduce a global usefla
On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny wrote:
> On Sun, 2 Sep 2012 17:09:22 +0200
> Fabio Erculiani wrote:
>
>> On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote:
>> >
>> >
>> > Why not introduce a global useflag such as "suggested-deps" which
>> > complies with GLEP 62 meaning it will be in
On Sun, 2 Sep 2012 17:09:22 +0200
Fabio Erculiani wrote:
> On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote:
> >
> >
> > Why not introduce a global useflag such as "suggested-deps" which
> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
> >
>
> How do you manage to fix the PDEPEND "id
On Sun, 2 Sep 2012 16:45:12 +0200
Fabio Erculiani wrote:
> Hi,
> this is actually a fork of the HDEPEND thread (sorry for having
> diverged that much there).
> As I wrote in the other thread, the problem with PDEPEND is that there
> are two (or more) semantics:
>
> - PDEPENDs used as "suggestion
On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote:
>
>
> Why not introduce a global useflag such as "suggested-deps" which
> complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
>
How do you manage to fix the PDEPEND "identity disorder" problem then?
Teaching devs to move to GLEP 62 is much har
On 09/02/2012 04:45 PM, Fabio Erculiani wrote:
> Hi,
> this is actually a fork of the HDEPEND thread (sorry for having
> diverged that much there).
> As I wrote in the other thread, the problem with PDEPEND is that there
> are two (or more) semantics:
>
> - PDEPENDs used as "suggestions" but yet b
Hi,
this is actually a fork of the HDEPEND thread (sorry for having
diverged that much there).
As I wrote in the other thread, the problem with PDEPEND is that there
are two (or more) semantics:
- PDEPENDs used as "suggestions" but yet being considered in the
depgraph and actually installed. Usual
On Tue, 15 Dec 2009 19:59:44 +0100, Fabian Groffen
wrote:
> With the current route where EAPI=3 will simply be EAPI=2 +
> offset-prefix support, and EAPI=4 will be EAPI=3 + some other stuff, the
> following question arose:
>
> Should an ebuild using an EAPI that has offset-prefix support make
On 16-12-2009 09:29:07 +0300, Peter Volkov wrote:
> В Втр, 15/12/2009 в 19:59 +0100, Fabian Groffen пишет:
> > Should an ebuild using an EAPI that has offset-prefix support make the
> > use of that support mandatory or optional?
>
> I think no. Without real testing that package works in prefix
В Втр, 15/12/2009 в 19:59 +0100, Fabian Groffen пишет:
> Should an ebuild using an EAPI that has offset-prefix support make the
> use of that support mandatory or optional?
I think no. Without real testing that package works in prefix there is
no need to bother and create illusion that it does
> On Tue, 15 Dec 2009, Fabian Groffen wrote:
> With the current route where EAPI=3 will simply be EAPI=2 +
> offset-prefix support,
That's not entirely right, as EAPI 3 will also include mtime
preservation.
> Should an ebuild using an EAPI that has offset-prefix support make the
> use of
With the current route where EAPI=3 will simply be EAPI=2 +
offset-prefix support, and EAPI=4 will be EAPI=3 + some other stuff, the
following question arose:
Should an ebuild using an EAPI that has offset-prefix support make the
use of that support mandatory or optional?
In other words, one
Hi everyone,
As you all know, it's somewhat annoying when a version bump in a
package such as xorg-server triggers a need to rebuild reverse
dependencies, and it would be really great if we could automate this.
We already have something that's very close to a solution in EAPI 3,
called the 'opera
2009-07-05 13:36:24 David Leverton napisał(a):
> On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote:
> > I would like to suggest that values of IUSE_* variables (whose names end
> > with values of USE_EXPAND variable), after prefixing with lower-cased names
> > of appropriate
On Sun, 5 Jul 2009 04:33:54 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> I would like to suggest that values of IUSE_* variables (whose names
> end with values of USE_EXPAND variable), after prefixing with
> lower-cased names of appropriate variables included in USE_EXPAND,
> should be autom
On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote:
> I would like to suggest that values of IUSE_* variables (whose names end
> with values of USE_EXPAND variable), after prefixing with lower-cased names
> of appropriate variables included in USE_EXPAND, should be automatica
I would like to suggest that values of IUSE_* variables (whose names end with
values of USE_EXPAND variable), after prefixing with lower-cased names of
appropriate variables included in USE_EXPAND, should be automatically added
to IUSE variable.
Example:
IUSE="abc"
IUSE_LINGUAS="en fr +la pl ru"
> On Tue, 31 Mar 2009, Christian Faulhammer wrote:
> Have a look at http://v-li.de/temp/eapi_cheatsheet.pdf>,
> print it, fold it and tell me if you like or not (and especially
> what exactly).
The Gentoo store should have a coffee mug with this. ;-)
Ulrich
On Wednesday 01 April 2009 11:37:58 Michael Haubenwallner wrote:
> On Tue, 2009-03-31 at 18:48 +, Ferris McCormick wrote:
> > On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote:
> > > Hi everyone,
> > >
> > > with EAPI 3 confusion about what is in which EAPI may increase,
> > > altho
On Tue, 2009-03-31 at 18:48 +, Ferris McCormick wrote:
> On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote:
> > Hi everyone,
> >
> > with EAPI 3 confusion about what is in which EAPI may increase,
> > although appendix E of the PMS is quite helpful here. Anyway,
> > something hand
On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote:
> Hi everyone,
>
> with EAPI 3 confusion about what is in which EAPI may increase,
> although appendix E of the PMS is quite helpful here. Anyway,
> something handy to put on your desk is my little EAPI leaflet which
> gives you all i
Hi everyone,
with EAPI 3 confusion about what is in which EAPI may increase,
although appendix E of the PMS is quite helpful here. Anyway,
something handy to put on your desk is my little EAPI leaflet which
gives you all important (in my eyes) information in one leaf. Have a
look at http://v-li.
On 00:39 Fri 05 Sep , Zac Medico wrote:
> David Leverton wrote:
> > 2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
> >> Both approaches are essentially equivalent but it's a little simpler
> >> for ebuild writer if they don't have to customize the output file name.
> >
> > But is it so much simpler
On Friday 05 September 2008 00:58:05 Zac Medico wrote:
> * Default phase function implementations for older EAPIs are
> accessible via functions having names that start with 'eapi',
> followed by the EAPI value.
Based on the lack of use cases or further responses to [1] I would suggest
remo
Alec Warner kirjoitti:
On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico <[EMAIL PROTECTED]> wrote:
David Leverton wrote:
2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file nam
On Friday 05 September 2008, Mike Auty wrote:
> From what I understand of the idea, the eclass will just change the
> SRC_URI field from the first case (sf=tgz) to the second case (->).
> Eclasses have to be sourced before the SRC_URI is determined because
> they can already add (and presumably alt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
> How is using the eclass better for bandwidth usage? It won't allow for
> mirroring, and all users would have to checkout the repository from one
> place. Furthermore, you cannot have (signed) Manifests that allow
> integrity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
> How is using the eclass better for bandwidth usage? It won't allow for
> mirroring, and all users would have to checkout the repository from one
> place. Furthermore, you cannot have (signed) Manifests that allow
> integrity
On Friday 05 September 2008, Fernando J. Pereda wrote:
> On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote:
> > David Leverton wrote:
> > > 2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
> > >> Both approaches are essentially equivalent but it's a little
> > >> simpler for ebuild writer if they
On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Leverton wrote:
>> 2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
>>> Both approaches are essentially equivalent but it's a little simpler
>>> for ebuild writer if they don't
On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote:
> David Leverton wrote:
> > 2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
> >> Both approaches are essentially equivalent but it's a little simpler
> >> for ebuild writer if they don't have to customize the output file name.
> >
> > But is it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
> 2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
>> Both approaches are essentially equivalent but it's a little simpler
>> for ebuild writer if they don't have to customize the output file name.
>
> But is it so much simpler as to jus
2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
> Both approaches are essentially equivalent but it's a little simpler
> for ebuild writer if they don't have to customize the output file name.
But is it so much simpler as to justify adding a special
gitweb-specific hack to the package managers?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
> 2008/9/4 Zac Medico <[EMAIL PROTECTED]>:
>> * The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
>> extensions, for interoperability with gitweb.
>>
>> * SRC_URI supports a syntax extension which allows customizati
2008/9/4 Zac Medico <[EMAIL PROTECTED]>:
> * The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
> extensions, for interoperability with gitweb.
>
> * SRC_URI supports a syntax extension which allows customization
> of output file names by using a "->" operator.
Is it useful to have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please review and discuss the following features which are proposed
for inclusion EAPI 2. As mentioned in my previous email [1], in
planning for this EAPI bump, we should strike a balance somewhere
in-between everything that we'd like to
On 08/26/05 Kristian Benoit wrote:
> On the EAPI subject Brian just brought back, I had this idea that we
> could use the same approch XML took with HTML.
>
> The ebuild could define which EAPI to use, but instead beiing a
> version, the EAPI would be an ebuild API definition. The equivalent to
On Fri, Aug 26, 2005 at 03:02:13PM -0700, Drake Wyrm wrote:
> Brian Harring <[EMAIL PROTECTED]> wrote:
> > B) EAPI is pretty much bash env template switching
> [snip]
>
> Perhaps the EAPI handling could be implemented using eclasses, rather
> than something in the deep, dark, python-based internal
Brian Harring <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote:
[snip]
> > the EAPI would be an ebuild API definition. The equivalent to the XML's
> > dtd. The ebuild could point to a directory named
> > $PORTDIR/eapi// which would contain a python script
Maybe I'm incorrect, but I believe Kristian was not saying use XML,
but using xml as a comparasison (I know there is a better word.. but
its escaping me... that comparassion thing on the SAT's). He's not
saying to use xml, but in order to extend portage, extend it much like
xml extends html, with
On Fri, 26 Aug 2005 15:32:42 -0500 Brian Harring <[EMAIL PROTECTED]>
wrote:
| A) what does xml bring to the table explicitly that is needed?
A cool three letter acronym. Portage is currently lacking in this
department. How are we expected to sell it to enterprise users if it
doesn't use XML?
--
On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote:
> On the EAPI subject Brian just brought back, I had this idea that we
> could use the same approch XML took with HTML.
>
> The ebuild could define which EAPI to use, but instead beiing a version,
> the EAPI would be an ebuild API de
On the EAPI subject Brian just brought back, I had this idea that we
could use the same approch XML took with HTML.
The ebuild could define which EAPI to use, but instead beiing a version,
the EAPI would be an ebuild API definition. The equivalent to the XML's
dtd. The ebuild could point to a dire
71 matches
Mail list logo
