public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian Harring <ferringb@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
Date: Wed, 28 Dec 2011 19:36:01 -0800	[thread overview]
Message-ID: <20111229033601.GA18706@localhost> (raw)
In-Reply-To: <CAD6zcDwraGKaqcvGVHihomWW-FYoy3fF4KACoBmbnQHVy5h+iA@mail.gmail.com>

On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote:
> 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.

Respectfully, the proposals thus far (including python eclass bit) are 
going in the opposite direction of maintainability, simplicity, 
robustness.

People have problems as is dealing w/ eclasses changing and their 
dependencies in external repositories not being updated; this 
complicates that issue and introduces the same potential into 
gentoo-x86 itself.  That's not beneficial.

Thing to keep in mind beyond the potential for confusion the proposals 
entail were they implemented, is the implementation itself.  
Timeslices?  python eclass api versions (when people have problems 
figuring out the existing, *singular* version)?  These things aren't 
going to be simple which means more than likely, they're going to 
break, and more than likely it's going to be a PITA to maintain it.

Per the norm, I could be wrong, but reading these proposals, they 
really feel like they need to revisit the notion of 
maintainability/robustness as an actual full fledged implementation, 
beyond the (admittedly semi nifty) notion of versioned apis.

My 2 cents, hopefully not at my usual offensive level-
~harring



  reply	other threads:[~2011-12-29  3:36 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
2011-12-29  3:36     ` Brian Harring [this message]
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=20111229033601.GA18706@localhost \
    --to=ferringb@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