[gentoo-dev] Re: [RFC] EAPI 2 Draft
Christian Faulhammer wrote: Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. One needs exceptions for all kind of systems, for example I had to workaround Trac which adds ?format=raw to a tarball URI. There seems to be a solution in Trac as the guys from fedarahosted fixed the two I needed (tmpwatch, mlocate). So the - operator is quite useful and I agree with David that the functionality is doubled. Clearly src-uri transformation is useful. Others have given examples of how it would be useful to an eclass. Irrespective of how the actual transform is done in the ;sf=tbz2 case, both _are_ valid use-cases. As such I don't see any reason not to put it in the EAPI. Future extensions can be trialled in eutils, and these can both be allowed syntax for other package managers to comply with (one implementation has already been given) and ebuild devs to feel comfortable using in the Gentoo tree. Why slow the innovation down? It's good enough for use as-is.
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
As per GMsoft request: Channel: #gentoo-hppa Contact: GMsoft, jer
Re: [gentoo-dev] Re: [RFC] EAPI 2 Draft
On Sat, Sep 06, 2008 at 12:43:12PM +0100, Steve Long wrote:
Christian Faulhammer wrote:
Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file
name.
One needs exceptions for all kind of systems, for example I had to
workaround Trac which adds ?format=raw to a tarball URI. There seems
to be a solution in Trac as the guys from fedarahosted fixed the two I
needed (tmpwatch, mlocate). So the - operator is quite useful and I
agree with David that the functionality is doubled.
Clearly src-uri transformation is useful. Others have given examples of how
it would be useful to an eclass. Irrespective of how the actual transform
is done in the ;sf=tbz2 case, both _are_ valid use-cases.
Sure they may be valid use cases, but the issue is whether the
;sf=tar.bz2 code is duplicated from '-'. I don't see any reason why you
can't use '-' to handle ;sf=tbz2, so they are duplicated. Since '-'
can be used in more circumstances(SRC_URI=http://foo.com/2.3/foo.bz2
- ${P}.tar.bz2 comes to mind), we don't need ;sf=tbz2.
pgpD0tA0gVKlo.pgp
Description: PGP signature
[gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
Also taken from Exherbo, DEFAULT_SRC_COMPILE_PARAMS could be used to
append parameters to emake like so:
src_compile() {
emake buildtarget
}
which would be replaced by:
DEFAULT_SRC_COMPILE_PARAMS=( 'buildtarget' )
This was originally proposed in bug #230725[1]
Regards,
Thomas
[1] https://bugs.gentoo.org/show_bug.cgi?id=230725
pgp7YUHyykivk.pgp
Description: PGP signature
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
And: #gentoo-mirrors Contact: fox2mike
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?
Also taken from Exherbo, DEFAULT_SRC_COMPILE_PARAMS could be used to
append parameters to emake like so:
src_compile() {
emake buildtarget
}
which would be replaced by:
DEFAULT_SRC_COMPILE_PARAMS=( 'buildtarget' )
This was originally proposed in bug #230725[1]
Regards,
Thomas
[1] https://bugs.gentoo.org/show_bug.cgi?id=230725
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 12:00 PM, Alec Warner [EMAIL PROTECTED] wrote:
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?
errr s/1/2/ s/line/lines/ :/
Also taken from Exherbo, DEFAULT_SRC_COMPILE_PARAMS could be used to
append parameters to emake like so:
src_compile() {
emake buildtarget
}
which would be replaced by:
DEFAULT_SRC_COMPILE_PARAMS=( 'buildtarget' )
This was originally proposed in bug #230725[1]
Regards,
Thomas
[1] https://bugs.gentoo.org/show_bug.cgi?id=230725
Re: [gentoo-dev] Re: [RFC] EAPI 2 Draft
On Sat, Sep 6, 2008 at 4:43 AM, Steve Long [EMAIL PROTECTED] wrote: Christian Faulhammer wrote: Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. One needs exceptions for all kind of systems, for example I had to workaround Trac which adds ?format=raw to a tarball URI. There seems to be a solution in Trac as the guys from fedarahosted fixed the two I needed (tmpwatch, mlocate). So the - operator is quite useful and I agree with David that the functionality is doubled. Clearly src-uri transformation is useful. Others have given examples of how it would be useful to an eclass. Irrespective of how the actual transform is done in the ;sf=tbz2 case, both _are_ valid use-cases. As such I don't see any reason not to put it in the EAPI. Future extensions can be trialled in eutils, and these can both be allowed syntax for other package managers to comply with (one implementation has already been given) and ebuild devs to feel comfortable using in the Gentoo tree. Why slow the innovation down? It's good enough for use as-is. Because then we have to wait for all the PM's to implement this magical code; where if we put it in eutils we can use it right now (and most overlays can use it too). 'Why slow the innovation down?' :) -Alec
[gentoo-dev] Re: [RFC] EAPI 2 Draft
Alec Warner schrieb: I think the question isn't 'why is this functionality being made available'; I think to me it is useful piece of code. I question its inclusion in the PM though; I would rather see it in eutils or something similar. Arguably you could inherit a function from eutils that does SRC_URI transformation for you. SRC_URI=foo bar baz;sf=tbz2 src_uri_gitize would transform baz;sf=tbz2 into baz;sf=tbz2 - baz.tar.bz2 Same applies to files that are fetched from trac so I also would question hard-coding a single use case into PM... Greetz -Jokey
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 9:00 PM, Alec Warner [EMAIL PROTECTED] wrote:
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?
In the given example it's not a big deal. However, when you're dealing
with more arguments it simplifies things.
For example, this (based on an existing ebuild, but simplified a bit
for brevity):
--
src_compile() {
local myconf=
--sysconfdir=/etc/${PN}
--without-xgrid
--enable-pretty-print-stacktrace
--enable-orterun-prefix-by-default
--without-slurm
if use threads; then
myconf=${myconf}
--enable-mpi-threads
--with-progress-threads
fi
econf ${myconf} \
$(use_enable !nocxx mpi-cxx) \
$(use_enable romio io-romio) \
$(use_enable heterogeneous) \
$(use_with pbs tm) \
$(use_enable ipv6) \
|| die econf failed
emake || die emake failed
}
--
becomes
--
SRC_DEFAULT_CONFIGURE_WITHS=( pbs tm ipv6 threads progress-threads
SRC_DEFAULT_CONFIGURE_ENABLES=(
cxx mpi-cxx
romio io-romio
heterogeneous
threads mpi-threads
SRC_DEFAULT_CONFIGURE_EXTRA_PARAMS=(
--sysconfdir=/etc/${PN}
--without-xgrid
--enable-pretty-print-stacktrace
--enable-orterun-prefix-by-default
--without-slurm )
--
You save some lines, but also you keep out all the use_* calls with
their backslashes, myconf=$myconf crap, econf/emake || die...
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
Alec Warner wrote:
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?
It may be 2 lines less, but it is 42 characters more.
Plus, I dislike caps. :-p
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 10:10 PM, Ben de Groot [EMAIL PROTECTED] wrote:
Alec Warner wrote:
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?
It may be 2 lines less, but it is 42 characters more.
Plus, I dislike caps. :-p
In the example I posted it's 339 characters less. Almost half of the
original ;-)
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
[gentoo-dev] FHS compliant KDE install and multi-version support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
Some members of the KDE team have been talking for some time about
having a FHS compliant install (define KDE prefix as /usr instead of
/usr/kde/version). The most important consequence of that option is
that it won't be possible to have 2 or more KDE versions installed at
the same time - it's important to note this restriction doesn't affect
kde-3.5 as it uses different eclasses that install it under /usr/kde/3.5
and the live version as everyone on the team seems to agree that it
should always be installed into /usr/kde/live-version.
We've been trying to find a way that will allow users to do an FHS
compliant install if they want it, while at the same time still allowing
those that are not interested in it to keep using the current scheme.
Our first attempt was to use a multislot use flag[1]. According to that
flag, we would set the SLOT and the PREFIX for the install. That has the
a very important problem - it breaks the invariancy of the SLOT and as
thus been put aside.
The next step was to use a kdeprefix use flag[2]. This flag no longer
touches the SLOT that is set to 4 for all kde-4.X versions. It only
determines if the package will be installed under the FHS compliant
location (/usr) or under the old location (/usr/kde/version). This
however means the users will no longer have the option to have more than
one kde-4.X version installed.
I've been thinking on a different method. With this method [3], we would
keep using the major.minor slots (4.1, 4.2, etc) so we also wouldn't
break the invariancy. We would allow users to select whether to have an
FHS compliant install or not (the way to allow that still needs to be
discussed) and we would set the prefix based on that. In case the user
wants an FHS compliant install, the eclasses would block all kde
packages on other slots - except 3.5 (uses other eclasses) and the live
versions (for the above reason that it will always be installed under
/usr/kde/live-version). One way to decide whether to install on an FHS
compliant location would be to add a use flag, but I don't think adding
that flag for 200+ ebuilds makes sense as it doesn't make sense to have
1 version of some packages and possibly 2 or more of other packages.
So, what am I after in this email? After having an internal discussion
and then opening it up to users in #gentoo-kde and a few other people on
#gentoo-portage, it was suggested I sent a mail here to open this
discussion to everyone and to present the case in a more clear manner.
So, can anyone suggest a good way to accomplish what were trying to do?
At least a better solution than the ones I've presented above? I would
also welcome suggestions on how to configure if the user wants an FHS
compliant install or not (I've thought about setting this var on /etc).
In case someone is thinking on suggesting it, ignoring FHS or not
allowing the install of multiple versions are not valid solutions to
this problem.
~ [1] - The commit where it was added was
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commitdiff;h=e3a8156bd504e4a377d4eedee123252136da821d
It boiled down to the following:
# setting the slot dep
~if [[ ${KDEBASE} == kde-base ]]; then
~case ${PV} in
~3.9*) _kdedir=3.9 ;;
- - 4.0.8*| 4.0.9* | 4.1*) _kdedir=4.1
- - _pv=-${PV}:4.1 ;;
+ 4.0.8*| 4.0.9* | 4.1*)
+ _kdedir=4.1
+ if use multislot; then
+ _pv=-${PV}:4.1
+ else
+ _pv=-${PV}:4
+ fi
+ ;;
# setting the prefix
- - KDEDIR=/usr/kde/${_kdedir}
- - KDEDIRS=/usr:/usr/local:${KDEDIR}
+ # If the multislot USE flag is set use multiple slots for minor
versions
+ if use multislot; then
+ KDEDIR=/usr/kde/${_kdedir}
+ KDEDIRS=/usr:/usr/local:${KDEDIR}
+ else
+ KDEDIR=/usr
+ KDEDIRS=/usr:/usr/local
+ fi
# setting the slot
+ # The svn versions always need their own slot
~if [[ -n ${KDEBASE} ]]; then
~if [[ ${NEED_KDE} = svn ]]; then
~SLOT=kde-svn
~else
- - case ${PV} in
- - 4.0.8* | 4.0.9* | 4.1*) SLOT=4.1 ;;
- - *) SLOT=kde-4 ;;
- - esac
+ # Assign the slot
+ if use multislot; then
+ case ${PV} in
+ 4.0.8* | 4.0.9* | 4.1*)
+ SLOT=4.1 ;;
+
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
On Sun, 2008-09-07 at 02:05 +, Jorge Manuel B. S. Vicetto wrote: I've been thinking on a different method. With this method [3], we would keep using the major.minor slots (4.1, 4.2, etc) so we also wouldn't break the invariancy. We would allow users to select whether to have an FHS compliant install or not (the way to allow that still needs to be discussed) and we would set the prefix based on that. In case the user wants an FHS compliant install, the eclasses would block all kde packages on other slots - except 3.5 (uses other eclasses) and the live versions (for the above reason that it will always be installed under /usr/kde/live-version). The big problem with that idea is that upgrading from one version to another will be very painful as portage will yell with a million blockers. The only proper way to do it is to stop the /usr/kde madness for everyone and just install everything in /usr like everyone else does, if upstream wanted it to be parallel installable, they would have made it that way (like gnome 1.x vs gnome 2.x). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
