Collecting opinions about GLEP 55 and alternatives
Hi!
My preference, most wanted to least wanted:
- inside the ebuild
If it's not too much pain. Yes, that is a very subjective
metric and it's what a large amount of flames has been about.
- in the filename, but not as a tail
eg: foo-2.3.4-r2+9.build
yes, alternate separators might be better.
I like .build very much, though. What does the e in ebuild
stand for anyway?
- in the filename, as a tail
eg: foo-2.3.4.ebuild-9
I don't like this much, but it's better than never having EAPI
versioning.
Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks.
[...]
I dislike GLEP 55 aesthetically, but I see no other way to move out of
this deadlock where we can't use new bash-features till years have
passed. So unless someone suggests a solution that allows us to have
EAPI as part of the ebuild without having to wait till hell freezes
over, I'm behind GLEP 55 as the least-bad solution.
/loki_val
02-25-2009, 09:59 AM
Michael Haubenwallner
Collecting opinions about GLEP 55 and alternatives
On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote:
> get opinions [..] to get some idea what the general developer pool thinks.
> only allowed to post a single reply to this thread
Thank you for that, I usually don't follow long threads, so apologies if
things have been discussed already.
Basically, I'm all for having GLEP55 "as good as possible" in favour of
"as soon as possible" before implementation, even if it fits my
thoughts quite good already (see below).
> 2) EAPI in file extension
IMO, this should define *how* to read the *final* EAPI from the ebuild.
The *how* does not necessarily mean to /source/ the ebuild, so the terms
"pre-source EAPI" and "post-source EAPI" IMHO are too strongly focussing
on "(bash)> source $EBUILD" when used in a generic GLEP. Eventually, the
"pre-source" EAPI could be called "major" EAPI, and the
"post-source" EAPI could be called "major.minor" EAPI (see below).
The "EAPI in file extension" also should define the filename-part of the
versioning rules.
> a) .ebuild-<eapi>
> c) .<eapi>.<new extension>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
"ignored by current portage" is an important point for me to
*theorethically* guarantee for a possible upgrade path even over long
time.
> 3) EAPI in locked down place in the ebuild
This "lock down" should be done by "EAPI in file extension" above.
"lock down" can mean any of: "post-source (real bash-source)",
"self-parse (grep?)", "fixed-byte/line-offset", "..."
My thoughts are to split EAPI into several levels (rename them however
you like):
entry-point:
Specifies how to read the "filename-scope" EAPI.
filename-scope EAPI:
Think as "major" EAPI.
Specifies the filename-part of versioning rules.
Specifies how to read the "global-scope" EAPI (can, but
eventually should not require bash-sourcing the ebuild).
May allow to not define "minor", assuming "$major.0.0" then.
global-scope EAPI:
Think as "$major.minor" EAPI.
May specify how to define additional versioning rules.
Specifies how to define metadata information.
Specifies which metadata information is
required/optional/cached/... Specifies how to utilize external
resources (eclasses).
Specifies which/how actions can/must be defined (pkg_*, src_*
functions).
Specifies how to read the "local-scope" EAPI.
May allow to not define "micro", assuming "$major.$minor.0"
then.
May disallow a "local-scope" EAPI, specifies it instead.
local-scope EAPI:
Think as "$major.$minor.micro" EAPI.
Specifies which PM-functions are available for use in actions
(fex 'doman' inside src_install).
May be specified as part of "minor" EAPI.
Thanks!
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
02-25-2009, 10:18 AM
Mike Auty
Collecting opinions about GLEP 55 and alternatives
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Petteri Räty wrote:
> 3) EAPI in locked down place in the ebuild
> c) .ebuild in current directory
> - needs one year wait
I'm all for 1 or 3c, because we're not in any rush.
I don't see why there's such an immediate need to make as drastic
changes as are being suggested for GLEP-55, simply to allow for the
possibility of future unknown ebuild mechanisms (like ebuilds not being
bash scripts). If ebuilds change significantly from their current form,
then and only then, would it be a good time to change the ebuild suffixes.
I don't want to get an attachment from bugzilla and find I have to try
four different file extensions because whilst the package and version
were obvious from the bug, the eapi number wasn't.
I also don't want to run into a situation where this package manager
supports kdebuilds, whilst that package manager supports gnomebuilds,
and a third one supports xfcebuilds. That's just recreating the browser
wars, and will leave us with the likes of IE6.
I'd be relatively happy with a shebang that specifies the parser or
passes the ebuild version, as long as it was standardized, linear and
supported by all the PMs (ie, some rogue PM can't suddenly start
allowing a "myeapi" that only it can build)...
Mike 5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Collecting opinions about GLEP 55 and alternatives
Petteri Räty <betelgeuse@gentoo.org> wrote:
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> c) .<eapi>.<new extension>
> - ignored by current Portage
Any of the above are fine with me, there is a demonstrated need for
this to introduce changes that current portage could not handle.
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
3.a is just like glep-55, except that the filename extension doesn't
change all the time. I like that this will have the benefits of
glep-55 plus the benefits of making happy the people who don't want the
EAPI in the filename or the extension to change very often.
This will effectively change a single EAPI number into a major/minor
pair. The major part (the extension name) would only ever change when
a major feature is introduced that breaks the current portage rules.
The internal EAPI, specified however we like in the major format
specification, could be in a fixed location or otherwise easily
parseable. Then small changes would alter this minor/internal EAPI
value.
--
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)
Wed Feb 25 14:30:01 2009
Return-path: <ubuntu-devel-bounces@lists.ubuntu.com>
Envelope-to: tom@linux-archive.org
Delivery-date: Wed, 25 Feb 2009 13:55:42 +0200
Received: from chlorine.canonical.com ([91.189.94.204]:55323)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <ubuntu-devel-bounces@lists.ubuntu.com>)
id 1LcIMY-0006Zy-Ga
for tom@linux-archive.org; Wed, 25 Feb 2009 13:55:42 +0200
Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com)
by chlorine.canonical.com with esmtp (Exim 4.60)
(envelope-from <ubuntu-devel-bounces@lists.ubuntu.com>)
id 1LcIQo-0006PQ-Ov; Wed, 25 Feb 2009 12:00:07 +0000
Received: from mail-fx0-f166.google.com ([209.85.220.166])
by chlorine.canonical.com with esmtp (Exim 4.60)
(envelope-from <ubuntu@bugabundo.net>)
id 1Laujj-0003ZF-Ql; Sat, 21 Feb 2009 16:29:55 +0000
Received: by fxm10 with SMTP id 10so747769fxm.14
for <multiple recipients>; Sat, 21 Feb 2009 08:29:55 -0800 (PST)
Received: by 10.223.115.16 with SMTP id g16mr2637494faq.93.1235233795359;
Sat, 21 Feb 2009 08:29:55 -0800 (PST)
Received: from blubug.localnet ([92.250.96.92])
by mx.google.com with ESMTPS id i6sm8660261gve.18.2009.02.21.08.29.52
(version=SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 08:29:54 -0800 (PST)
From: "(=?iso-8859-1?q?``-_-´´?=) -- BUGabundo"
<ubuntu@bugabundo.net>
Organization: Ubuntu LoCoTeam Portugal http://ubuntu-pt.org
To: ubuntu-devel-discuss@lists.ubuntu.com
Subject: Improving resume speed
Date: Sat, 21 Feb 2009 16:23:32 +0000
User-Agent: KMail/1.11.0 (Linux/2.6.28-8-generic; KDE/4.2.0; x86_64; ; )
X-Face: ~}'<3p"*yj,xO6NSrZxSF:8+:ARG}z+uBcQFI6(6Esp}B9HXF }#f<#F4,
=?utf-8?q?Zk`X8`nkyp~
jGc3z8mjoC_3:0[Wo?;3^T1D5Jn*y? =?utf-8?q?cy&nt?=>4Q5!hgs{6s,
=?utf-8?q?0]0_wuWI+TVBYY:.?;7dMIv
|-WTTUv1?AUcH~?=<&KY4Xf3a!`-n8Q?3a_93'HYJw[G5g?xg-a@UOF*4be/2Y1@Kh(
=?utf-8?q?eZE|
%}er$/d.ck9Y?#=m+$PW4m8?=)
=?utf-8?q?UiP1$k;*k-`q4`TEO|wIWR`Bbcz^mc}c#l35p]rG/? =?utf-8?q?axh-
TSf%[QOD]263P?=,
*+m$+3YFpTi{.}iB`Ir|grbLo`F/3ldsx""
=?utf-8?q?G4F.5.|rZlg}D`k4Ip
bT$22uNZ?=(n
MIME-Version: 1.0
Message-Id: <200902211623.33663.Ubuntu@bugabundo.net>
X-Mailman-Approved-At: Wed, 25 Feb 2009 11:57:38 +0000
Cc: ubuntu-devel@lists.ubuntu.com
X-BeenThere: ubuntu-devel@lists.ubuntu.com
X-Mailman-Version: 2.1.8
Precedence: list
Reply-To: ubuntu-reply@bugabundo.net, ubuntu-devel-discuss@lists.ubuntu.com
List-Id: "Ubuntu Development (developers)" <ubuntu-devel.lists.ubuntu.com>
List-Unsubscribe: <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel>,
<mailto:ubuntu-devel-request@lists.ubuntu.com?subject=unsubscribe>
List-Archive: <https://lists.ubuntu.com/archives/ubuntu-devel>
List-Post: <mailto:ubuntu-devel@lists.ubuntu.com>
List-Help: <mailto:ubuntu-devel-request@lists.ubuntu.com?subject=help>
List-Subscribe: <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel>,
<mailto:ubuntu-devel-request@lists.ubuntu.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="==============?90967634699254912=="
Mime-version: 1.0
Sender: ubuntu-devel-bounces@lists.ubuntu.com
Errors-To: ubuntu-devel-bounces@lists.ubuntu.com
Jaunty had/has the objective to have a fast startup (<25 secs),
But the current technique to resume hibernated machines (using the kernel mode) is too slow, and doesnt use compression.
pm-utils (pm-hibernate via s2disk) currently does this, and have a much nicer UI (it shows progress), but unfortunately it got broken last weekend on jaunty [1].
Since we are past FF, is there any interest in fixing this for koala? Either by improving the kernel mode, or using s2disk.
Some devs keep mentioning that this approach brakes many setups, but it I have never had probs it with on all my machines, and it even works when the kernel mode doesnt.
Maybe we can set an easier option for an user to change this (other then to alter /etc/pm/config.d/00sleep_module), or use one, and then fallback to the other if this fails.
https://bugs.launchpad.net/bugs/331101
--
Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by...
--nextPart15079835.ssygkqoHeg
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--==============?90967634699254912==--
02-25-2009, 11:49 AM
Brian Harring
Collecting opinions about GLEP 55 and alternatives
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
> My notes so far:
>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage
>
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait
4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as
the first statement (simplest way).
pros:
- global scope changes can occur (inherit mechanism changes
included).
- expanding on the first, auto inherits (pkg level) are possible-
effectively when eapi gets invoked the manager is in control and
can do whatever is desired setting up the env wise.
- bash version requirements can be leveled (bash parses as it goes,
meaning that essentially it won't parse what follows 'eapi 2' till
that command statement finishes)
- fits w/ the existing semantics nicely enough.
cons:
- mangling the version rules for pkgs still isn't possible; no -scm.
Arguable if -scm is even desired, but being explicit about it not
covering this.
- transition is slightly icky; basically one of the following is
required-
a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason
for this is that current managers obviously lack an eapi function,
to make managers available *now* blow up the || die is required.
This solution can be deployed now, no transition required although
at some point stating "eapi is required retroactively for all
eapis" would be wise to eliminate the need for the || die (cut
support basically for old managers)
b) bashrc trickery, defines an eapi if it's unset. Said eapi
function exports EAPI=$1, optionally triggering a die if the eapi
isn't 0,1,2 (since any later eapi would require a manager upgrade
which would also have the eapi function).
Personally, if g54 is ixnayed #4 I tend to think is the best option
out there- if g54 is forced in, g55 (or at least something that
adjusts the extension to make it invisible to current managers) is
required.
Commentary? Tend to think #4 is the most aesthetically pleasing to
folk, but who knows...
~harring
02-25-2009, 01:33 PM
Robert Buchholz
Collecting opinions about GLEP 55 and alternatives
On Tuesday 24 February 2009, Petteri Räty wrote:
> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in
> order to get some idea what the general developer pool thinks.
Thanks for opening a spot to voice our opinions within reasonable limits
and without deadlocked discussions.
To make it brief, I'd very much prefer 3c[0] for the reasons provided by
others before:
- From what I can see, it provides for all requirements set out by g55.
- There is a backwards-compatible way to implement it.
- It does not expose any more internal metadata than current ebuilds do.
- I see no rush to implement new EAPI features that require drastic
changes enabled by 1*.
- It provides a constant face for Gentoo, aka we're the guys and gals
using the ".ebuild" format.
Robert
[0] Although not with a fixed line limit, but with a strict way to find
it, i.e. the first occurence of #?s*EAPI=["']?([a-zA-Z0-9._]+)["']?
or similar.
02-25-2009, 06:03 PM
Thomas Anderson
Collecting opinions about GLEP 55 and alternatives
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
Yuck, I want per-package eclasses and all those other goodies.
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage
2a please, though .ebuild.eapi would be fine as well. My reasons are
mostly contained in Antarus' glep revision, and the fact that there have
been no real valid(IMO) objections.
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait
These are all ugly.(c is the worst).
Oh, And I certainly hope this is not Democracy(you know what they say,
democracy is two wolves and a sheep deciding who to have for dinner)
Looking forward to the council meeting, where there will *hopefully* be
a decision.
Thomas
--
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------
02-25-2009, 08:00 PM
Joe Peterson
Collecting opinions about GLEP 55 and alternatives
Ulrich Mueller wrote:
>>>>>> On Wed, 25 Feb 2009, Petteri Räty wrote:
>
>> Let's try something new. I would like to get opinions from as many
>> people as possible about GLEP 55 and alternatives listed here in order
>> to get some idea what the general developer pool thinks.
>
> I've already commented on this in December 2007 [1], and my opinion
> hasn't changed.
>
>> 1) Status quo
>> 2) EAPI in file extension
>> 3) EAPI in locked down place in the ebuild
>> a) <new extension>
>> b) new subdirectory like ebuilds/
>> c) .ebuild in current directory
>
> Acceptable for me would be 1) and 3c).
I have also stated my opinion before. But I agree with Ulrich.
-Joe
02-25-2009, 08:09 PM
Josh Saddler
Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote:
> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a useful
> experiment to see if we can control ourselves
>
> My notes so far:
>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait
Leave EAPI inside the ebuild. That's where I want to find it.
Oh, and as others have mentioned, CVS sucks for file renaming and
versions. Yet another reason to leave it inside the ebuild.
Collecting opinions about GLEP 55 and alternatives
