[gentoo-dev] [RFC] obs eclasses

[gentoo-dev] [RFC] obs eclasses

[Michal Hrusecky]

[-- Attachment #1.1: Type: text/plain, Size: 221 bytes --]

Hi,

please take a look at attached eclasses. Purpose is to make installation
of obs services (plugins for osc) easier.

Comments and improvements are welcome.

Regards

-- 
	Michal Hrusecky <miska@gentoo.org>

[-- Attachment #1.2: obs-download.eclass --]
[-- Type: text/plain, Size: 1516 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: obs-download.eclass
# @MAINTAINER:
# miska@gentoo.org
# @BLURB: Reduces code duplication in the downloading from obs.
# @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}"

[-- Attachment #1.3: obs-service.eclass --]
[-- Type: text/plain, Size: 2375 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: obs-service.eclass
# @MAINTAINER:
# miska@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.
#
# @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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Amadeusz Żołnowski]

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

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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Joshua Kinard]

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

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


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

Re: [gentoo-dev] [RFC] obs eclasses

[Amadeusz Żołnowski]

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

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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Michał Górny]

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

On Tue, 13 Sep 2011 15:02:43 +0200
Amadeusz Żołnowski <aidecoe@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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Michal Hrusecky]

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

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 <miska@gentoo.org>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Donnie Berkholz]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Donnie Berkholz]

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

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:
> # miska@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:
> # miska@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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Nirbheek Chauhan]

On Tue, Sep 13, 2011 at 8:29 PM, Donnie Berkholz <dberkholz@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

[Patrick Lauer]

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

[Donnie Berkholz]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Ulrich Mueller]

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

[Tomáš Chvátal]

2011/9/13 Ulrich Mueller <ulm@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

[Amadeusz Żołnowski]

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

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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Michał Górny]

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

On Tue, 13 Sep 2011 19:25:59 +0200
Ulrich Mueller <ulm@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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Ulrich Mueller]

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

[Michał Górny]

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

On Tue, 13 Sep 2011 20:40:12 +0200
Ulrich Mueller <ulm@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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Ciaran McCreesh]

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

On Tue, 13 Sep 2011 17:58:15 +0200
Patrick Lauer <patrick@gentoo.org> 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.

The proper fix for this, along with a whole bunch of other things, is
GLEP 55. Don't blame the PMS team for that not having been implemented.

As for you ignoring the specification, the reason that problems like
this exist is precisely because of you doing that. Do you code websites
based purely upon what Internet Explorer supports?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] obs eclasses

[Ciaran McCreesh]

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

On Tue, 13 Sep 2011 11:41:00 -0500
Donnie Berkholz <dberkholz@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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Michal Hrusecky]

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

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:
> > # miska@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:
> > # miska@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 <miska@gentoo.org>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Michal Hrusecky]

[-- Attachment #1.1: Type: text/plain, Size: 122 bytes --]

Hi,

new versions of eclasses after hopefully fixing most of the comments.

-- 
	Michal Hrusecky <miska@gentoo.org>

[-- Attachment #1.2: obs-download.eclass --]
[-- Type: text/plain, Size: 1514 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: obs-download.eclass
# @MAINTAINER:
# miska@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}"

[-- Attachment #1.3: obs-service.eclass --]
[-- Type: text/plain, Size: 2419 bytes --]

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: obs-service.eclass
# @MAINTAINER:
# miska@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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Ulrich Mueller]

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

[Michal Hrusecky]

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

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 <miska@gentoo.org>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] [RFC] obs eclasses

[Marijn]

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

[Michal Hrusecky]

-----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 <miska@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iF4EAREIAAYFAk5xtNwACgkQpMQOFjUY7FXlQwEAqyoRWVzPxdq7Bf43wnPaeCXr
o/jw7aKw8bCYokTEDlgA/306yyqBmePvSast4nOJJSg6KPi6QcLusC81QJJlKu9K
=I8KK
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [RFC] obs eclasses

[Duncan]

Michal Hrusecky posted on Thu, 15 Sep 2011 10:18:36 +0200 as excerpted:

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

Taking a hint from the existing eclass name patterns, I'd strongly urge 
open-build.eclass or the like, over obs.eclass, which is intuitively read 
as "obsolete" (or in a medical context, obstetrics), here.

Similarly with its vars and functions.  obs_* is simply not immediately 
readable to many of those who may end up looking at ebuilds using it (I'm 
not the only one who has mentioned it), and were it me proposing it, I'd 
be particularly anxious to avoid the negative implications and confusion 
of someone reading "obsolete" into such references.

But of course I'm not the primary target audience or the person that's 
going to end up typing it in repeatedly, so...

-- 
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: [RFC] obs eclasses

[Steven J Long]

Joshua Kinard wrote:

> On 09/13/2011 07:24, Amadeusz Żołnowski wrote:
> 
>> You don't need -n/-z with [[.
>> 
>>   [[ $var ]] == [[ -n $var ]]
>>   [[ ! $var ]] == [[ -z $var ]]
>>
Also, you can usually be more succinct with [[ $var ]] || { some code; } for 
the empty case (as opposed to [[ $var ]] && { something else; } for code run 
when var is non-empty.)

> 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.
>
As Amadeusz said, you can't omit the other ones.

> Also, is this a bash4-only thing, or bash3 and/or bash2 as well?
>
It was definitely around in all bash-3 versions, from experience, and it's 
also a defined behaviour for POSIX sh test or [, tho only guaranteed for XSI 
systems[1] so I'd be surprised if it weren't in bash-2.

> 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
>
As Michal said, it doesn't do any harm. imo it'd be better just to add that 
[[ $var ]] is the same as [[ -n $var ]]. [[ ! $var ]] doesn't seem better 
than [[ -z $var ]] to my eyes; the latter is clearer imo.

(Decrufting ${var} to $var would be more of a help for learners imo; you 
only need to wrap a simple variable expansion in {} when it's immediately 
followed by an alphanumeric or underscore character, which would get 
interpreted as part of its name, which any syntax highlighting editor will 
show you. In several years of BASH scripting I've only once had an issue 
with that, in some complex text output.)
> Oh, forgot, it won't break initscripts, will it?
> 
Well you wouldn't use [[ in a sh-compatible initscript in any case. There 
it'd be safest to stick to [ -n "$var" ] (or -z ofc.)

[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] [RFC] obs eclasses

[Michał Górny]

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

On Tue, 13 Sep 2011 13:11:28 +0200
Michal Hrusecky <miska@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

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

Re: [gentoo-dev] [RFC] obs eclasses

[Tomáš Chvátal]

2011/9/20 Michał Górny <mgorny@gentoo.org>:
> On Tue, 13 Sep 2011 13:11:28 +0200
> Michal Hrusecky <miska@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