Re: [gentoo-dev] zeroconf/avahi USE flag
Daniel Gryniewicz a écrit : > I agree. Let's just have zeroconf. +1, zeroconf is what it should be called, regardless of different implementations (especially if they are compatible). Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [gentoo-dev] zeroconf/avahi USE flag
2008/11/4 Doug Goldstein <[EMAIL PROTECTED]>: > bonjour is Apple specific branding for zeroconf. This is another case > that needs to be changed. I just came up with this as nobody mentioned it before :-) > zeroconf/avahi/howl/bonjour/mdnsresponder all need to be condensed. ++ one flag for all implementations. -- Regards, Daniel
[gentoo-dev] Re: Reinstating eclasses
Duncan wrote: > Joe Peterson wrote: >> In general, it makes sense to me to have an unversioned one if there is >> no version dependency - i.e. if xfce.eclass would likely work for future >> ones (like "xfce5"). I'm not sure why, other than to emphasize that a >> new version is out, upstream packages (like gnome, kde, etc.) include >> the version in the name. I actually just think of kde as "kde", myself, >> even if it happens to be version 4. ;) > > FWIW, KDE changes major versions seldom enough and with enough > differences between versions, that it's a good time to break package > handling and get rid of the cruft at the Gentoo level as well. That's a valid reason, although eclass versioning (which someone, can't mem who, not a portage dev, told me was round the corner) would solve it more cleanly across the tree and allow the simplest name. The attraction of staying with one name is that the eclass can transition ebuilds and then lose the cruft once the packages are out of tree. Given that eclasses can test and change according to EAPI, what we have now would seem sufficient unless there is a major build system change, like KDE4 switching to cmake. > Presuming something similar for xfce, if xfce4 is taken but xfce isn't, > that would work, or perhaps xfce4ng.eclass... *ng is always good for a > round... and if it comes to it beyond that, g3, g4, etc. Of course, > that's sort of like Gentoo's -rX numbers for ebuilds, but the -rX concept > doesn't so well lend itself to the eclass concept as it implies a rather > faster turnover than we'd /hope/ to be the case, but -ng/-gX, that works. > =:^) > I like that naming schema but think it might be overkill here. Might be a more flexible way to do epochs, but I'm not sure we'd need more than one comparable value, and I think sticking to one int is sufficient.
[gentoo-dev] Re: Flags to punt (including: kerberos USE flag)
David Leverton wrote: > On Monday 03 November 2008 04:29:34 Nirbheek Chauhan wrote: >> Why not use EAPI=1 for those ebuilds and turn the flag on by default? > > Well, as I said, it seems more sensible to me to set the default once, > instead > of once for each ebuild. I don't particularly care, though, just making > sure people know why it was there in the first place, and if they still > want to change it, so be it. I concur, it is more sensible. Dunno how you get round the maintenance issue, apart from scripts around the time someone leaves or sth. Maybe "if they're all/substantively from an eclass, it definitely must not be in a profile" would be a good policy.
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
Peter Alfredsen schrieb:
> On Monday 03 November 2008, Steve Long wrote:
>> Peter Alfredsen wrote:
>>> debug-print-function $FUNCNAME $*
>> You should be using "$@" not unquoted $*.
>
> Fixed. Also fixed base_src_unpack and base_src_compile calling their
> grunt functions with $1, when clearly it should have been [EMAIL PROTECTED]
>
>> Seems like the FUNCNAME bit should just be rolled into the function
>> with "${FUNCNAME[1]}" which could be done tree-wide quite easily.
>
> I guess that function was written before bash-3 when FUNCNAME was turned
> into an array.
>
>
>
You should at least use emake instead of make in src_install. And i would
suggest to use something
like this instead of the make install line (maybe add some other default docs,
if they are common):
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
emake DESTDIR="${D}" install || die "emake install failed"
fi
if [ -n "${DOCS}" ]; then
dodoc ${DOCS} || die "dodoc failed"
else
for x in AUTHORS ChangeLog NEWS README; do
if [ -e ${x} ]; then
dodoc ${x} || die "dodoc ${x} failed"
fi
done
fi
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
On Wednesday 05 November 2008, Thomas Sachau wrote:
> You should at least use emake instead of make in src_install. And i
> would suggest to use something like this instead of the make install
> line (maybe add some other default docs, if they are common):
>
> if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
> emake DESTDIR="${D}" install || die "emake install failed"
> fi
> if [ -n "${DOCS}" ]; then
> dodoc ${DOCS} || die "dodoc failed"
> else
> for x in AUTHORS ChangeLog NEWS README; do
> if [ -e ${x} ]; then
> dodoc ${x} || die "dodoc ${x} failed"
> fi
> done
> fi
I only propose changes to update the base.eclass to using EAPI-2
functions, IOW the above is outside the scope of what I propose.
Besides, using emake instead of make is not a good change to make to an
eclass unless you know for a fact that all ebuilds using the eclass
have parallel make friendly makefiles. And even then...
--
/PA
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
Peter Alfredsen schrieb:
> On Wednesday 05 November 2008, Thomas Sachau wrote:
>
>> You should at least use emake instead of make in src_install. And i
>> would suggest to use something like this instead of the make install
>> line (maybe add some other default docs, if they are common):
>>
>> if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
>> emake DESTDIR="${D}" install || die "emake install failed"
>> fi
>> if [ -n "${DOCS}" ]; then
>> dodoc ${DOCS} || die "dodoc failed"
>> else
>> for x in AUTHORS ChangeLog NEWS README; do
>> if [ -e ${x} ]; then
>> dodoc ${x} || die "dodoc ${x} failed"
>> fi
>> done
>> fi
>
> I only propose changes to update the base.eclass to using EAPI-2
> functions, IOW the above is outside the scope of what I propose.
>
> Besides, using emake instead of make is not a good change to make to an
> eclass unless you know for a fact that all ebuilds using the eclass
> have parallel make friendly makefiles. And even then...
>
So change your src_compile ;-)
Do you really think, a package that supports parallel make while compiling
fails support for
parallel make support on install?
And emake is and still should be the default. If there is an issue with it, the
ebuild author has to
change his ebuild. But this should not be taken to force only one makejob for
everyone else.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aqbanking3-tool: ChangeLog aqbanking3-tool-0.0.20081026.ebuild
On Wed, Nov 05, 2008 at 09:04:16AM +, Hanno Boeck (hanno) wrote: > hanno 08/11/05 09:04:16 > > Added:ChangeLog aqbanking3-tool-0.0.20081026.ebuild > Log: > aqbanking3-tool initial commit > (Portage version: 2.2_rc13/cvs/Linux 2.6.28-rc3-git1 x86_64) Please remember to include a metadata.xml! (Newer repoman is going to catch this automatically). -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpYOJEtCzgOF.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
On Wed, 05 Nov 2008 21:20:07 +0100 Thomas Sachau <[EMAIL PROTECTED]> wrote: > Do you really think, a package that supports parallel make while > compiling fails support for parallel make support on install? Yup, that's fairly common. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
On Wed, Nov 05, 2008 at 09:20:07PM +0100, Thomas Sachau wrote: > Peter Alfredsen schrieb: > Do you really think, a package that supports parallel make while compiling > fails support for > parallel make support on install? Happened for jabberd and jabberd2 to me. pgpjnLZOswT2t.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
Hi, > And emake is and still should be the default. If there is an issue with it, > the ebuild author has to > change his ebuild. But this should not be taken to force only one makejob for > everyone else. > But with rotating storage, don't you (very much) only want one I/O-bound job at a time? Regards, T.
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
Thomas Sachau wrote: > Do you really think, a package that supports parallel make while compiling > fails support for > parallel make support on install? > See bug 196728. It's an (old) automake issue. > And emake is and still should be the default. If there is an issue with it, > the ebuild author has to > change his ebuild. But this should not be taken to force only one makejob for > everyone else. > On Gentoo/FreeBSD where "make" is BSD make, emake knows when to use "gmake" instead, so pretty please, use emake instead of make.
