From: Francesco Riosa <vivo75@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
Date: Thu, 29 Dec 2011 02:37:07 +0000 [thread overview]
Message-ID: <CAD6zcDwraGKaqcvGVHihomWW-FYoy3fF4KACoBmbnQHVy5h+iA@mail.gmail.com> (raw)
In-Reply-To: <4EFB6C24.1070307@gentoo.org>
2011/12/28 Zac Medico <zmedico@gentoo.org>:
> On 12/28/2011 05:12 AM, Francesco Riosa wrote:
>> Seem to me that append a time slice to the function, in the name or as
>> a parent function that call the underling function can solve most of
>> the versioning/deprecation problems
>
> I've overheard Arfrever discussing a similar approach in funtoo's irc
> channel, where the ebuild would set a variable prior to inherit if it
> wants to use a specific eclass API. For the python eclass, he's planning
> to have ebuilds set the PYTHON_ECLASS_API variable to use the new API.
> When the variable is unset, the eclass will default to the older API.
There is a fundamental difference, with "timeslices" it's not the
ebuild that select the implementation but the point in time it's used,
or the user forcing a fake time. From what I've read Artfever approach
require changes in every ebuild and keeping old functions forever. On
the other hand it may be risky to change the preferred interface from
the eclass and not the ebuild.
Thanks for reviewing,
Francesco
next prev parent reply other threads:[~2011-12-29 2:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-28 13:12 [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds Francesco Riosa
2011-12-28 19:01 ` Zac Medico
2011-12-29 2:28 ` Francesco Riosa
2011-12-28 19:21 ` Zac Medico
2011-12-29 2:37 ` Francesco Riosa [this message]
2011-12-29 3:36 ` Brian Harring
2011-12-29 10:49 ` Francesco Riosa
2011-12-29 15:28 ` Jeroen Roovers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD6zcDwraGKaqcvGVHihomWW-FYoy3fF4KACoBmbnQHVy5h+iA@mail.gmail.com \
--to=vivo75@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox