Donnie Berkholz <dberkholz@gentoo.org>:
> On 23:35 Sun 08 Mar , Tiziano Müller wrote:
> > Well, the point I'm trying to make here is a different one: The
> > syntax you proposed is more to write but still equivalent to the
> > one using vars. And looking at the ebuilds - taking G2CONF as an
> > example - it seems that people don't have a problem with putting
> > their config options into vars. And furthermore with your syntax
> > you still have to write out "econf $(use_with ...)" explicitly
> > while adding it the conf-vars to a var (as proposed) makes the
> > complete src_configure function obsolete, allows the usage of the
> > default src_configure/src_compile/src_install (see
> > http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml
> > for example) and is therefore even shorter to write.
>
> I think the idea of ebuilds as scripts showing directly how to build
> software is a core part of the Gentoo build-system philosophy. This
> proposal pushes ebuilds toward a formatted file that is not a script.
> Instead, it is more like an Ant XML file that more abstractly
> describes a build. I think this is the wrong direction for ebuilds
> because they should directly resemble how software is built by hand.
I agree with you here, the saving of space by not defining a custom
src_configure() stands against readability for non-developers (also
known as people who do not work with ebuilds on a daily basis but still
regularly). We gain only a little bit.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
<URL:http://www.faulhammer.org/>
03-09-2009, 08:06 AM
Christian Faulhammer
Ideas for a (fast) EAPI=3
Hi,
Daniel Pielmeier <daniel.pielmeier@googlemail.com>:
> 2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
> >
> > *I don't know if there is a bug somewhere (I did not find one), but
> > what about having the possibility to ask for one out many USE flags
> > of a dependency. *For example app-misc/gramps needs dev-lang/python
> > with USE=berkdb or USE=sqlite, but Portage won't tell the user that
> > he can enable one but always asks for the first in the || () string.
> >
>
> || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
That's the solution currently and not the optimum.
> The only way I found to get around this is to recompile python with
> the new use flags first. Afterwards dependency calculation succeeds.
Well spotted.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
<URL:http://www.faulhammer.org/>
03-09-2009, 08:12 AM
Michael Haubenwallner
Ideas for a (fast) EAPI=3
On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote:
> I think the idea of ebuilds as scripts showing directly how to build
> software is a core part of the Gentoo build-system philosophy. This
> proposal pushes ebuilds toward a formatted file that is not a script.
> Instead, it is more like an Ant XML file that more abstractly describes
> a build. I think this is the wrong direction for ebuilds because they
> should directly resemble how software is built by hand.
Fully agreed here, "keep it simple software".
Even if there are slightly more bits to write in the ebuilds.
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
03-09-2009, 08:13 AM
Daniel Pielmeier
Ideas for a (fast) EAPI=3
2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
> Hi,
>
> Daniel Pielmeier <daniel.pielmeier@googlemail.com>:
>>
>> || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
>
> *That's the solution currently and not the optimum.
>
I have discussed this yesterday with loki_val, and workaround would be
using a useflag for one database backend and if it is deactivated use
the other.
Am Montag, den 09.03.2009, 10:06 +0100 schrieb Christian Faulhammer:
> Hi,
>
> Daniel Pielmeier <daniel.pielmeier@googlemail.com>:
>
> > 2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
> > >
> > > I don't know if there is a bug somewhere (I did not find one), but
> > > what about having the possibility to ask for one out many USE flags
> > > of a dependency. For example app-misc/gramps needs dev-lang/python
> > > with USE=berkdb or USE=sqlite, but Portage won't tell the user that
> > > he can enable one but always asks for the first in the || () string.
> > >
> >
> > || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
>
> That's the solution currently and not the optimum.
>
> > The only way I found to get around this is to recompile python with
> > the new use flags first. Afterwards dependency calculation succeeds.
>
Correctly you should probably add a berkdb or sqlite USE flag to gramps
and then do:
sqlite? ( dev-lang/python[sqlite] )
!sqlite? ( dev-lang/python[berkdb] )
Because if the user currently installs gramps and has
dev-lang/python[sqlite] and then later decides to reinstall
dev-lang/python with USE=-sqlite, everything's fine from a package
managers view as long as dev-lang/python has at least USE=berkdb, but
the user looses the data in gramps.
Well, even then it's not safe since it's python and gramps may offer
berkdb as a storage backend even if USE=sqlite, so you should patch
gramps to blend out what's not available from a dependency
perspective...
03-09-2009, 08:17 AM
Tiziano Müller
Ideas for a (fast) EAPI=3
Am Sonntag, den 08.03.2009, 23:31 -0700 schrieb Donnie Berkholz:
> On 21:22 Sun 08 Mar , Donnie Berkholz wrote:
> > On 23:35 Sun 08 Mar , Tiziano Müller wrote:
> > > Well, the point I'm trying to make here is a different one: The syntax
> > > you proposed is more to write but still equivalent to the one using
> > > vars. And looking at the ebuilds - taking G2CONF as an example - it
> > > seems that people don't have a problem with putting their config
> > > options into vars. And furthermore with your syntax you still have to
> > > write out "econf $(use_with ...)" explicitly while adding it the
> > > conf-vars to a var (as proposed) makes the complete src_configure
> > > function obsolete, allows the usage of the default
> > > src_configure/src_compile/src_install (see
> > > http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml
> > > for example) and is therefore even shorter to write.
> >
> > I think the idea of ebuilds as scripts showing directly how to build
> > software is a core part of the Gentoo build-system philosophy. This
> > proposal pushes ebuilds toward a formatted file that is not a script.
> > Instead, it is more like an Ant XML file that more abstractly describes
> > a build. I think this is the wrong direction for ebuilds because they
> > should directly resemble how software is built by hand.
> >
> > One of the key reasons people use Gentoo is that ebuilds are so easy to
> > "get" for anyone who has ever built software by hand. I will continue to
> > vehemently defend anything that I think retains this key advantage of
> > Gentoo over other distributions.
>
> To return to the original point of this whole thread, your goal was to
> get EAPI=3 through fairly quickly without tons of controversial points.
> I don't think this component qualifies. Feel free to bring it up again
> for 4.
Wanted to say the same thing. Removed from the list.
03-09-2009, 05:01 PM
Tobias Scherbaum
Ideas for a (fast) EAPI=3
Am Montag, den 09.03.2009, 10:12 +0100 schrieb Michael Haubenwallner:
> On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote:
>
> > I think the idea of ebuilds as scripts showing directly how to build
> > software is a core part of the Gentoo build-system philosophy. This
> > proposal pushes ebuilds toward a formatted file that is not a script.
> > Instead, it is more like an Ant XML file that more abstractly describes
> > a build. I think this is the wrong direction for ebuilds because they
> > should directly resemble how software is built by hand.
>
> Fully agreed here, "keep it simple software".
> Even if there are slightly more bits to write in the ebuilds.
dito, fully agreed.
Tobias
03-09-2009, 07:26 PM
Ciaran McCreesh
Ideas for a (fast) EAPI=3
On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller <dev-zero@gentoo.org> wrote:
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
Here're some more easy ones.
First up, un-optionaling some optional things. No impact for developers:
* PROPERTIES must be cached properly (it's optional in current EAPIs)
* DEFINED_PHASES must be supported (ditto)
Next, some probably easy but long standing features:
* src_test run unless RESTRICTed or explicitly disabled by the user (bug
184812)
* have econf run ./configure with --disable-dependency-tracking and
--enable-fast-install (bug 211529)
* Limit values in $USE to ones in $IUSE (bug 176467). The existing
behaviour's majorly annoying; time for the package manager to start
enforcing things strictly.
Some things we should probably sort out:
* The list of extensions for unpack probably needs a couple of new
things.
* Provide ebuilds a way to differentiate between updates and removals
(bug 205557), since the way devmanual says to do it got broken by a
non-EAPIed change. This one's slightly trickier than initially
apparent, because a solution's needed for the weird cases. One
example is if you have foo-1:1 and foo-2:2 installed, and you're
installing foo-2:1. In this case, it's both a reinstall and an
upgrade. One possibility is a REPLACING_VERSIONS variable that
contains a list of all versions being replaced, along with a
REPLACED_BY_VERSION variable for the pre/postrm part.
Not sure if these can go in in time for Portage or not:
* Utility commands, even the ones that aren't functions, should die. To
get a non-die version, prefix the command with nonfatal (e.g.
'nonfatal dodoc README', which just returns non-zero on failure
rather than splatting).
* Calling unpack on an unrecognised extension should be fatal, unless
--if-compressed is specified. The default src_unpack needs to use
this.
* pkg_info should work on things that aren't installed, as well as
things that are.
--
Ciaran McCreesh
03-09-2009, 07:56 PM
Zac Medico
Ideas for a (fast) EAPI=3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ciaran McCreesh wrote:
> * Limit values in $USE to ones in $IUSE (bug 176467). The existing
> behaviour's majorly annoying; time for the package manager to start
> enforcing things strictly.
My impression is that most ebuild developers tend to dislike the
idea of adding profile-specific flags such as $ARCH, userland_*,
kernel_*, and elibc_* to IUSE. Perhaps there should be exemptions
for these?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
On Mon, 09 Mar 2009 13:56:19 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > * Limit values in $USE to ones in $IUSE (bug 176467). The existing
> > behaviour's majorly annoying; time for the package manager to
> > start enforcing things strictly.
>
> My impression is that most ebuild developers tend to dislike the
> idea of adding profile-specific flags such as $ARCH, userland_*,
> kernel_*, and elibc_* to IUSE. Perhaps there should be exemptions
> for these?
If we must do that... Can we get something in profiles a bit like this:
Ideas for a (fast) EAPI=3
