Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 13:11:28 +0200 Michal Hrusecky mi...@gentoo.org wrote: please take a look at attached eclasses. Purpose is to make installation of obs services (plugins for osc) easier. Comments and improvements are welcome. I don't get the concept of having two eclasses for this. The first one looks more like a thirdpartymirrors entry. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
2011/9/20 Michał Górny mgo...@gentoo.org: On Tue, 13 Sep 2011 13:11:28 +0200 Michal Hrusecky mi...@gentoo.org wrote: please take a look at attached eclasses. Purpose is to make installation of obs services (plugins for osc) easier. Comments and improvements are welcome. I don't get the concept of having two eclasses for this. The first one looks more like a thirdpartymirrors entry. Not really, you can't use variables in third-party mirrors, and storing there all opensuse releases or opensuse projects to check is REALLY insane as the package is usually just on one project. So it is not a mirror at all, rather one download url with really complex path. Tom
Re: [gentoo-dev] [RFC] obs eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michal, On 09/14/11 10:56, Michal Hrusecky wrote: Hi, new versions of eclasses after hopefully fixing most of the comments. The download eclass speaks about ``openSUSE Build Service'' while the other calls it the ``Open Build Service''. I note that the command line tool dev-util/osc also speaks about ``Open Build Service''. Others have remarked on this, but could you please explain why there are (going to be) ebuilds that don't/cannot use the full eclass? What numbers are we talking about? How about using open-build-service in the name of the eclass(es)? Finally, has this seen any testing in an overlay? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5xqtgACgkQp/VmCx0OL2w+aACffzDKZkDMOiKE55hh5CAS3b27 JA0AnRDZmVM3W/BuLBK0VPQEmIsYh0u6 =S84c -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] obs eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Marijn - 9:35 15.09.11 wrote: Hi Michal, On 09/14/11 10:56, Michal Hrusecky wrote: Hi, new versions of eclasses after hopefully fixing most of the comments. The download eclass speaks about ``openSUSE Build Service'' while the other calls it the ``Open Build Service''. I note that the command line tool dev-util/osc also speaks about ``Open Build Service''. Things are a little bit complicated. Once upon a time, there were some people unhappy with the process of building packages for SUSE/openSUSE and they created server application and called it openSUSE Build Service. As openSUSE Build Service is quite a long name, everybody started calling it just 'obs'. Even developers themselves. As obs supported building packages for many distributions and was open source, some other companies and organizations started using it (for example Meego). Some didn't even know what 'obs' stands for and assumed, that 'o' is for 'Open'. But some other knew and was reluctant to use it because of openSUSE in it's name. So it got renamed to 'Open Build Service' (so the 'obs' abbreviation will still work). But the original first running publicly available instance is still called 'openSUSE Build Service'. So we've got a software, which is called Open Build Service and tools like dev-util/osc and it's plugins (obs services - what is second eclass intended for) that works with any instance. And we've got openSUSE Build Service which is basically build.opensuse.org server running Open Build Service :-D And as some SUSE guys are lazy to be a good upstream, they publish some source code and packages just through the openSUSE Build Service (that's what is the first eclass good for). Others have remarked on this, but could you please explain why there are (going to be) ebuilds that don't/cannot use the full eclass? What numbers are we talking about? Currently, there are two more ebuilds that can make a use of obs-download.eclass: 'dev-util/osc' and 'dev-util/suse-build'. It is not that much of code duplication, but I think it could make ebuilds more readable. How about using open-build-service in the name of the eclass(es)? I personally dislike long file names and obs is well known abbreviation (in my google search, second link is http://guild.opensuse.org and first http://en.wikipedia.org/wiki/OBS which also list OBS as Open Build Service), although a little bit ambiguous. If it would be hard requirement for getting them in, I would consider expanding the 'obs', but personally I would prefer not to. Finally, has this seen any testing in an overlay? Only locally - on my computer. Currently I have 3 services (osc plugins) that I needed to commit stuff with osc from git. - -- Michal Hrusecky mi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iF4EAREIAAYFAk5xtNwACgkQpMQOFjUY7FXlQwEAqyoRWVzPxdq7Bf43wnPaeCXr o/jw7aKw8bCYokTEDlgA/306yyqBmePvSast4nOJJSg6KPi6QcLusC81QJJlKu9K =I8KK -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] obs eclasses
Donnie Berkholz - 9:59 13.09.11 wrote: On 13:11 Tue 13 Sep , Michal Hrusecky wrote: # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ # @ECLASS: obs-download.eclass Are there going to be lots of packages using this and not the other eclass? I wonder whether there really need to be two of them. Two more currently. # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the downloading from obs. Could you tell us what obs is in the blurb too? I had no clue what this email was about (obs, osc, etc are meaningless to me) until I got down to the eclass description. Fixed # @ECLASS: obs-service.eclass # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the obs services. # @DESCRIPTION: # This eclass makes it easier to package obs services. Based on provided # information it will all neede variables and takes care of installation. Lots of typos here. Sorry, fixed. HOMEPAGE=http://en.opensuse.org/openSUSE:OSC; LICENSE=GPL-2 SLOT=0 IUSE= RDEPEND+=dev-util/osc You probably want a space here. RDEPEND+= dev-util/osc Thanks, fixed. -- Michal Hrusecky mi...@gentoo.org signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] obs eclasses
Hi,
new versions of eclasses after hopefully fixing most of the comments.
--
Michal Hrusecky mi...@gentoo.org
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: obs-download.eclass
# @MAINTAINER:
# mi...@gentoo.org
# @BLURB: Simplifies downloading from openSUSE Build Service.
# @DESCRIPTION:
# This eclass constructs OBS_URI based on provided project in openSUSE Build
# Service and package name. It can be used later by packages/eclasses to
# download actual files.
#
# All you need to do in order to use it is set OBS_PROJECT and OBS_PACKAGE and
# inherit this eclass. It will provide OBS_URI in return which you will prepend
# to your files and use in SRC_URI. Alternatively you can just set
# OPENSUSE_RELEASE and OBS_PACKAGE and it will give you back OBS_URI for
# downloading files from obs projects corresponding to the specified openSUSE
# release.
# @ECLASS-VARIABLE: OPENSUSE_RELEASE
# @DEFAULT_UNSET
# @DESCRIPTION:
# From which stable openSUSE realease to take files.
# @ECLASS-VARIABLE: OBS_PROJECT
# @DEFAULT_UNSET
# @DESCRIPTION:
# In which obs project pakage is. This variable don't have to be set, if
# OPENSUSE_RELEASE is provided.
# @ECLASS-VARIABLE: OPENSUSE_PACKAGE
# @REQUIRED
# @DESCRIPTION:
# Name of the package we want to take files from.
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
OBS_URI=https://api.opensuse.org/public/source/${OBS_PROJECT}/${OBS_PACKAGE};
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: obs-service.eclass
# @MAINTAINER:
# mi...@gentoo.org
# @BLURB: Reduces code duplication in the Open Build Service services.
# @DESCRIPTION:
# This eclass makes it easier to package Open Build Service services. Based on
# provided information it will set all needed variables and takes care of
# installation.
#
# @EXAMPLE:
# Typical ebuild using obs-service.eclass:
#
# @CODE
# EAPI=4
#
# inherit obs-service
#
# KEYWORDS=
#
# DEPEND=
# RDEPEND=${DEPEND}
#
# @CODE
# @ECLASS-VARIABLE: OBS_SERVICE_NAME
# @DESCRIPTION:
# Name of the service. If not set, it is taken from ${PN}.
# @ECLASS-VARIABLE: OPENSUSE_RELEASE
# @DESCRIPTION:
# From which stable openSUSE realease to take a package.
# @ECLASS-VARIABLE: ADDITIONAL_FILES
# @DEFAULT_UNSET
# @DESCRIPTION:
# If any additional files are needed.
case ${EAPI:-0} in
4) : ;;
*) die EAPI=${EAPI} is not supported ;;
esac
HOMEPAGE=http://en.opensuse.org/openSUSE:OSC;
LICENSE=GPL-2
SLOT=0
IUSE=
RDEPEND=dev-util/osc
[[ -n ${OBS_SERVICE_NAME} ]] || OBS_SERVICE_NAME=${PN/obs-service-/}
[[ -n ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:Tools
DESCRIPTION=Open Build Service client module - ${OBS_SERVICE_NAME} service
OBS_PACKAGE=obs-service-${OBS_SERVICE_NAME}
inherit obs-download
SRC_URI=${OBS_URI}/${OBS_SERVICE_NAME}
SRC_URI+= ${OBS_URI}/${OBS_SERVICE_NAME}.service
for i in ${ADDITIONAL_FILES}; do
SRC_URI+= ${OBS_URI}/${i}
done
S=${WORKDIR}
# @FUNCTION: obs-service_src_configure
# @DESCRIPTION:
# Does nothing. Files are not compressed.
obs-service_src_unpack() {
debug-print-function ${FUNCNAME} $@
}
# @FUNCTION: obs-service_src_install
# @DESCRIPTION:
# Does the installation of the downloaded files.
obs-service_src_install() {
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
doexe ${DISTDIR}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
doexe ${DISTDIR}/${i}
done
fi
}
EXPORT_FUNCTIONS src_install src_unpack
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] obs eclasses
On Wed, 14 Sep 2011, Michal Hrusecky wrote:
new versions of eclasses after hopefully fixing most of the comments.
# @ECLASS-VARIABLE: OPENSUSE_RELEASE
# @ECLASS-VARIABLE: OBS_PROJECT
# @ECLASS-VARIABLE: OPENSUSE_PACKAGE
Can't this use a single namespace, i.e. either OBS or OPENSUSE?
Otherwise people will get confused ...
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
... including yourself. ;-)
Ulrich
Re: [gentoo-dev] [RFC] obs eclasses
Ulrich Mueller - 11:56 14.09.11 wrote: On Wed, 14 Sep 2011, Michal Hrusecky wrote: new versions of eclasses after hopefully fixing most of the comments. # @ECLASS-VARIABLE: OPENSUSE_RELEASE # @ECLASS-VARIABLE: OBS_PROJECT # @ECLASS-VARIABLE: OPENSUSE_PACKAGE Can't this use a single namespace, i.e. either OBS or OPENSUSE? Otherwise people will get confused ... Ok, fixed the documentation, replaced OPENSUSE_PACKAGE with OBS_PACKAGE. OBS is whole service that can host pretty much anything. OPENSUSE_RELEASE is just to make it easier to take files from one particular project (that I'll be using for stable releases of some packages). So it has some reasons to have different prefix... -- Michal Hrusecky mi...@gentoo.org signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] obs eclasses
Hi,
Excerpts from Michal Hrusecky's message of 2011-09-13 13:11:28 +0200:
Comments and improvements are welcome.
Just some minor remarks:
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
You don't need -n/-z with [[.
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
So:
[[ ${OPENSUSE_RELEASE} ]] OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
obs-service_src_install() {
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
doexe ${DISTDIR}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print ${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
doexe ${DISTDIR}/$i
just in case.
done
fi
}
--
Amadeusz Żołnowski
PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On 09/13/2011 07:24, Amadeusz Żołnowski wrote:
Hi,
Excerpts from Michal Hrusecky's message of 2011-09-13 13:11:28 +0200:
Comments and improvements are welcome.
Just some minor remarks:
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
You don't need -n/-z with [[.
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
What about other comparisons, like -f, -e, or -d? Bash's manpage only says
[[ expression ]] -- it doesn't seem to go into the level of detail (at least
not in the section that I quickly perused) about what flag operators are
necessary or not.
Also, is this a bash4-only thing, or bash3 and/or bash2 as well?
If yes to above, we should get this edited and fixed up, then, because it
uses -z/-n inside [[ ]]:
http://devmanual.gentoo.org/tools-reference/bash/index.html
Oh, forgot, it won't break initscripts, will it?
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between.
--Emperor Turhan, Centauri Republic
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] obs eclasses
Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 15:02:43 +0200 Amadeusz Żołnowski aide...@gentoo.org wrote: OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? It was to prevent Arfrever from doing insane things :D. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
Amadeusz Żołnowski - 13:24 13.09.11 wrote:
Hi,
Excerpts from Michal Hrusecky's message of 2011-09-13 13:11:28 +0200:
Comments and improvements are welcome.
Just some minor remarks:
[[ -z ${OPENSUSE_RELEASE} ]] || OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ -n ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ -n ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
You don't need -n/-z with [[.
But they don't do any harm either, right ;-)
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
So:
[[ ${OPENSUSE_RELEASE} ]] OBS_PROJECT=openSUSE:${OPENSUSE_RELEASE}
[[ ${OBS_PROJECT} ]] || die OBS_PROJECT not set!
[[ ${OBS_PACKAGE} ]] || die OBS_PACKAGE not set!
obs-service_src_install() {
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
doexe ${DISTDIR}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print ${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
doexe ${DISTDIR}/$i
just in case.
Fixed.
--
Michal Hrusecky mi...@gentoo.org
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] obs eclasses
On 15:02 Tue 13 Sep , Amadeusz Żołnowski wrote: Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp6rUsNsnKPn.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On 13:11 Tue 13 Sep , Michal Hrusecky wrote: # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ # @ECLASS: obs-download.eclass Are there going to be lots of packages using this and not the other eclass? I wonder whether there really need to be two of them. # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the downloading from obs. Could you tell us what obs is in the blurb too? I had no clue what this email was about (obs, osc, etc are meaningless to me) until I got down to the eclass description. # @ECLASS: obs-service.eclass # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the obs services. # @DESCRIPTION: # This eclass makes it easier to package obs services. Based on provided # information it will all neede variables and takes care of installation. Lots of typos here. HOMEPAGE=http://en.opensuse.org/openSUSE:OSC; LICENSE=GPL-2 SLOT=0 IUSE= RDEPEND+=dev-util/osc You probably want a space here. RDEPEND+= dev-util/osc -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpkPf2od7LwK.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, Sep 13, 2011 at 8:29 PM, Donnie Berkholz dberkh...@gentoo.org wrote: HOMEPAGE=http://en.opensuse.org/openSUSE:OSC; LICENSE=GPL-2 SLOT=0 IUSE= RDEPEND+=dev-util/osc You probably want a space here. RDEPEND+= dev-util/osc Slightly bike-sheddy, but it's less error-prone to use: RDEPEND=dev-util/osc iirc, portage handles merging of the values of *DEPEND defined in eclasses and ebuilds. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] obs eclasses
On 09/13/11 16:44, Donnie Berkholz wrote: On 15:02 Tue 13 Sep , Amadeusz Żołnowski wrote: Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. Actually it's worse - PMS enforces this, and the only clean way out is to patch/fix/extend PMS to allow bash4 - but that breaks compatibility in silly ways. The proper way to handle that? I'm not sure, since we had a long fight to get PMS to acknowledge bash 3.2 instead of 3.0 I'm mostly ignoring PMS as it doesn't care about reality. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. That's not quite correct for this case, but it shows that we need to discuss destructive changes (in the sense that they are not backwards-compatible etc.) to have any decent progress
Re: [gentoo-dev] [RFC] obs eclasses
On 17:58 Tue 13 Sep , Patrick Lauer wrote: On 09/13/11 16:44, Donnie Berkholz wrote: It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. Actually it's worse - PMS enforces this, and the only clean way out is to patch/fix/extend PMS to allow bash4 - but that breaks compatibility in silly ways. The proper way to handle that? I'm not sure, since we had a long fight to get PMS to acknowledge bash 3.2 instead of 3.0 I'm mostly ignoring PMS as it doesn't care about reality. Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. That's not quite correct for this case, but it shows that we need to discuss destructive changes (in the sense that they are not backwards-compatible etc.) to have any decent progress Maybe a way to set tree-level dependencies/EAPIs/features is something we seriously need to get going on. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpdqwj5WnNHA.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. Ulrich
Re: [gentoo-dev] [RFC] obs eclasses
2011/9/13 Ulrich Mueller u...@gentoo.org: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. I would really like if we do it properly this time. So it is done for goot and does not reappear from time to time. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. As is Ulrich saying, it was done because everyone at that point was using such features. Not because we wanted those features to be used. Cheers Tom
Re: [gentoo-dev] [RFC] obs eclasses
Excerpts from Ulrich Mueller's message of 2011-09-13 19:25:59 +0200: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. Ulrich So we need to do it “illegally” first to make it “legal”? -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 19:25:59 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 13 Sep 2011, Donnie Berkholz wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. If you read the quoted council log, you'll find that the retroactive change was done because usage of bash 3.2 features in the tree was already widespread at that time. This is very different from the current situation, therefore it is not at all a precedent. The current situation is that you can't even install bash-3.2 systemwide because of the number of packages [ebuilds/eclasses] requiring on bash-4. I myself had to prefix-install bash to test my code against it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011, Michał Górny wrote: The current situation is that you can't even install bash-3.2 systemwide because of the number of packages [ebuilds/eclasses] requiring on bash-4. Have you filed bug reports for these? Ulrich
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 20:40:12 +0200 Ulrich Mueller u...@gentoo.org wrote: On Tue, 13 Sep 2011, Michał Górny wrote: The current situation is that you can't even install bash-3.2 systemwide because of the number of packages [ebuilds/eclasses] requiring on bash-4. Have you filed bug reports for these? I mean having *DEPEND==bash-4. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, 13 Sep 2011 11:41:00 -0500 Donnie Berkholz dberkh...@gentoo.org wrote: Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. The last time this happened, the Council said we're doing this once because people have forced our hand, but we're never doing it again. That's not a precedent. Maybe a way to set tree-level dependencies/EAPIs/features is something we seriously need to get going on. No need. GLEP 55 solves it with a far lower impact. -- Ciaran McCreesh signature.asc Description: PGP signature
