[gentoo-dev] Reinstating eclasses

[gentoo-dev] Reinstating eclasses

[Christoph Mende]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Hi,

I'm currently working on a new eclass for Xfce4 that, as opposed to the
previous ones (xfce42.eclass, xfce44.eclass), is supposed to be used
for all versions. Now the most logical name for an eclass like that
would be xfce4.eclass, except that eclass already exists. It seems like
it was used for Xfce 4.2 and has been deprecated for quite some time
now. Obviously, packages using that eclass (which is zero in the main
tree and zero in the xfce herd's overlay btw) wouldn't work with my new
eclass, so I can't just extend said eclass. Now my big question is: Do
I have to think of a new name for my eclass (was thinking of something
like xfce4-r1.eclass, which I don't really like though) or can I just
overwrite the old eclass?

-- 
Christoph Mende
Gentoo/AMD64 Operational Lead and Release Engineering
GPG: EE2A 454A 6A3B A2D8 E43B  FF45 2A19 C3B3 6DA0 C1AF

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Reinstating eclasses

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Mende wrote:
> Hi,
> 
> I'm currently working on a new eclass for Xfce4 that, as opposed to the
> previous ones (xfce42.eclass, xfce44.eclass), is supposed to be used
> for all versions. Now the most logical name for an eclass like that
> would be xfce4.eclass, except that eclass already exists. It seems like
> it was used for Xfce 4.2 and has been deprecated for quite some time
> now. Obviously, packages using that eclass (which is zero in the main
> tree and zero in the xfce herd's overlay btw) wouldn't work with my new
> eclass, so I can't just extend said eclass. Now my big question is: Do
> I have to think of a new name for my eclass (was thinking of something
> like xfce4-r1.eclass, which I don't really like though) or can I just
> overwrite the old eclass?
> 

Considering that stable portage (2.1.4.4) uses environment.bz2 and
doesn't need the eclasses to exist for uninstall or binary packages,
and it's exceedingly unlikely that it will hurt anyone, I think you
should go ahead and overwrite the old eclass.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkQh8EACgkQ/ejvha5XGaPvGACdFZMsZTAr6Qi9nyD1/zd24eb6
j00AoKBfHSrXPwUMSsC1WhSwvUVvVgad
=aINW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Reinstating eclasses

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Zac Medico wrote:
> Christoph Mende wrote:
>> Hi,
> 
>> I'm currently working on a new eclass for Xfce4 that, as opposed to the
>> previous ones (xfce42.eclass, xfce44.eclass), is supposed to be used
>> for all versions. Now the most logical name for an eclass like that
>> would be xfce4.eclass, except that eclass already exists. It seems like
>> it was used for Xfce 4.2 and has been deprecated for quite some time
>> now. Obviously, packages using that eclass (which is zero in the main
>> tree and zero in the xfce herd's overlay btw) wouldn't work with my new
>> eclass, so I can't just extend said eclass. Now my big question is: Do
>> I have to think of a new name for my eclass (was thinking of something
>> like xfce4-r1.eclass, which I don't really like though) or can I just
>> overwrite the old eclass?
> 
> 
> Considering that stable portage (2.1.4.4) uses environment.bz2 and
> doesn't need the eclasses to exist for uninstall or binary packages,
> and it's exceedingly unlikely that it will hurt anyone, I think you
> should go ahead and overwrite the old eclass.
>

The names of eclasses aren't shown to users and I think figuring out a
new name is a minor inconvenience so I would just go with the safe route.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Reinstating eclasses

[Joe Peterson]

Petteri Räty wrote:
> The names of eclasses aren't shown to users and I think figuring out a
> new name is a minor inconvenience so I would just go with the safe route.

I disagree: we should use care in choosing names, since these names will be
around for a long time.  Using an ugly name might not be visible to the users
so much, but we, as devs, need to see them, and we might as well be elegant
where possible.

							-Joe

Re: [gentoo-dev] Reinstating eclasses

[Joe Peterson]

Christoph Mende wrote:
> Now the most logical name for an eclass like that
> would be xfce4.eclass, except that eclass already exists.

Since the new eclass is not version specific, how about simply "xfce.eclass"?

					-Joe

[gentoo-dev] Re: Reinstating eclasses

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Tue, 04 Nov 2008 13:43:55 -0500
Joe Peterson <lavajoe@gentoo.org> wrote:

> Christoph Mende wrote:
> > Now the most logical name for an eclass like that
> > would be xfce4.eclass, except that eclass already exists.
> 
> Since the new eclass is not version specific, how about simply
> "xfce.eclass"?

why bother introducing yet another xfce*.eclass when you can re-use an
existing one?

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Reinstating eclasses

[Joe Peterson]

Ryan Hill wrote:
> On Tue, 04 Nov 2008 13:43:55 -0500
> Joe Peterson <lavajoe@gentoo.org> wrote:
> 
>> Christoph Mende wrote:
>>> Now the most logical name for an eclass like that
>>> would be xfce4.eclass, except that eclass already exists.
>> Since the new eclass is not version specific, how about simply
>> "xfce.eclass"?
> 
> why bother introducing yet another xfce*.eclass when you can re-use an
> existing one?

Well, my thought (without knowing xfce details, albeit) if the eclass is now
not tied to version, having one with no version info in the name might serve
future xfce versions (5, 6, 7...) as well without requiring yet another name
change.

						-Joe

Re: [gentoo-dev] Re: Reinstating eclasses

[Christoph Mende]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On Tue, 4 Nov 2008 13:15:25 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Tue, 04 Nov 2008 13:43:55 -0500
> Joe Peterson <lavajoe@gentoo.org> wrote:
> 
> > Christoph Mende wrote:
> > > Now the most logical name for an eclass like that
> > > would be xfce4.eclass, except that eclass already exists.
> > 
> > Since the new eclass is not version specific, how about simply
> > "xfce.eclass"?

Well, the desktop is usually called Xfce4, plus that'd match gnome2...
and more or less kde4

> why bother introducing yet another xfce*.eclass when you can re-use an
> existing one?
> 
That's what I want to do :P
We currently have xfce4.eclass, xfce42.eclass and xfce44.eclass. 42 and
44 are obviously versioned, 4 isn't, but isn't nearly compatible with
my new one, partly because it was used (and probably exclusively
written) for 4.2.

-- 
Christoph Mende
Gentoo/AMD64 Operational Lead and Release Engineering
GPG: EE2A 454A 6A3B A2D8 E43B  FF45 2A19 C3B3 6DA0 C1AF

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Reinstating eclasses

[Joe Peterson]

Christoph Mende wrote:
> Well, the desktop is usually called Xfce4, plus that'd match gnome2...
> and more or less kde4

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.  ;)

						-Joe

[gentoo-dev] Re: Reinstating eclasses

[Duncan]

Joe Peterson <lavajoe@gentoo.org> posted 4910A2C7.3030703@gentoo.org,
excerpted below, on  Tue, 04 Nov 2008 14:30:15 -0500:

> 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.  In the 
case of KDE4, before anything even close to stable ever hit the tree, the 
Gentoo/KDE folks took the opportunity to require various EAPI-2 features 
including sets, thereby removing much of the cruft and maintainability 
headaches of the kde3 packages and their corresponding eclasses.  kde4 
eclasses were then the logical choice, since the unversioned kde 
nameslots were already taken, and if/when there's a kde5, as with kde4, 
it's likely to be so different it'll be time to once again break with the 
past and use an entirely new setup, new eclasses, etc.

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. 
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Reinstating eclasses

[Steve Long]

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.