public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Steve Long <slong@rathaus.eclipse.co.uk>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev]  Re: Reinstating eclasses
Date: Wed, 05 Nov 2008 16:19:48 +0000	[thread overview]
Message-ID: <gesh5g$jrh$1@ger.gmane.org> (raw)
In-Reply-To: pan.2008.11.04.23.30.43@cox.net

Duncan wrote:

> Joe Peterson wrote:
>> In general, it makes sense to me to have an unversioned one if there is
>> no version dependency - i.e. if xfce.eclass would likely work for future
>> ones (like "xfce5").  I'm not sure why, other than to emphasize that a
>> new version is out, upstream packages (like gnome, kde, etc.) include
>> the version in the name.  I actually just think of kde as "kde", myself,
>> even if it happens to be version 4.  ;)
> 
> FWIW, KDE changes major versions seldom enough and with enough
> differences between versions, that it's a good time to break package
> handling and get rid of the cruft at the Gentoo level as well.

That's a valid reason, although eclass versioning (which someone, can't mem
who, not a portage dev, told me was round the corner) would solve it more
cleanly across the tree and allow the simplest name. The attraction of
staying with one name is that the eclass can transition ebuilds and then
lose the cruft once the packages are out of tree. Given that eclasses can
test and change according to EAPI, what we have now would seem sufficient
unless there is a major build system change, like KDE4 switching to cmake.

> Presuming something similar for xfce, if xfce4 is taken but xfce isn't,
> that would work, or perhaps xfce4ng.eclass...  *ng is always good for a
> round... and if it comes to it beyond that, g3, g4, etc.  Of course,
> that's sort of like Gentoo's -rX numbers for ebuilds, but the -rX concept
> doesn't so well lend itself to the eclass concept as it implies a rather
> faster turnover than we'd /hope/ to be the case, but -ng/-gX, that works.
> =:^)
> 
I like that naming schema but think it might be overkill here. Might be a
more flexible way to do epochs, but I'm not sure we'd need more than one
comparable value, and I think sticking to one int is sufficient.





      reply	other threads:[~2008-11-05 16:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04 16:43 [gentoo-dev] Reinstating eclasses Christoph Mende
2008-11-04 17:35 ` Zac Medico
2008-11-04 18:22   ` Petteri Räty
2008-11-04 18:30     ` Joe Peterson
2008-11-04 18:43 ` Joe Peterson
2008-11-04 19:15   ` [gentoo-dev] " Ryan Hill
2008-11-04 19:19     ` Joe Peterson
2008-11-04 19:23     ` Christoph Mende
2008-11-04 19:30       ` Joe Peterson
2008-11-04 23:30         ` Duncan
2008-11-05 16:19           ` Steve Long [this message]

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='gesh5g$jrh$1@ger.gmane.org' \
    --to=slong@rathaus.eclipse.co.uk \
    --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