[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/cairo: cairo-1.8.0.ebuild
On Sat, Sep 27, 2008 at 12:48:41AM +, Saleem Abdulrasool (compnerd) wrote: > compnerd08/09/27 00:48:41 > > Added:cairo-1.8.0.ebuild > Log: > version bump > (Portage version: 2.2_rc9/cvs/Linux 2.6.27-rc3-git3 i686) > > Revision ChangesPath > 1.1 x11-libs/cairo/cairo-1.8.0.ebuild Please do NOT forget to commit a ChangeLog with every substantial commit to a package, particularly when you add a new revision or other file! (Packages.g.o whines at me when it detects it). -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpaQehyANNmF.pgp Description: PGP signature
Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
Nirbheek Chauhan schrieb:
> On Wed, Sep 24, 2008 at 4:51 AM, Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote:
>> On Tuesday 23 September 2008 21:39:52 Thomas Sachau wrote:
>
>>> if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
> [...]
>>> fi
>
> - So if those makefiles don't exist, the package should just carry on
> without installing anything?
This is imho a good idea, else virtuals and meta packages would need an extra
(empty) src_install().
>
>>> if emake DESTDIR="${D} install || einstall ; then
>>> die "install failed"
>
> - The above code will cause a die when either one of emake install or
> einstall are *successful*. The opposite behaviour is desired.
Eh, sure, my mistake.
>
>>> else
>>> if [[ -n ${DOCS} ]]; then
>>> dodoc ${DOCS} || die "dodoc failed"
>>> fi
>
> - So, if emake install || einstall fails, one should just install the
> docs? The opposite behaviour is desired.
see above
>
> If a default src_install is desired, it should cater to the most
> common use-cases and leave it to the maintainer to override it if
> desired.
>
> default_src_install() {
> emake DESTDIR="${D}" install || die "emake install failed"
> if [ -n "${DOCS}" ]; then
> dodoc ${DOCS} || die "dodoc failed"
> else
> # No die here because we don't know if any of these exist
> dodoc AUTHORS ChangeLog NEWS README
> fi
> }
>
So what about this one?
default_src_install() {
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
# No die here because we don't know if any of these exist
dodoc AUTHORS ChangeLog NEWS README
fi
}
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/cairo: cairo-1.8.0.ebuild
Robin H. Johnson kirjoitti: On Sat, Sep 27, 2008 at 12:48:41AM +, Saleem Abdulrasool (compnerd) wrote: compnerd08/09/27 00:48:41 Added:cairo-1.8.0.ebuild Log: version bump (Portage version: 2.2_rc9/cvs/Linux 2.6.27-rc3-git3 i686) Revision ChangesPath 1.1 x11-libs/cairo/cairo-1.8.0.ebuild Please do NOT forget to commit a ChangeLog with every substantial commit to a package, particularly when you add a new revision or other file! (Packages.g.o whines at me when it detects it). Fixing this bug for repoman should help. http://bugs.gentoo.org/show_bug.cgi?id=171962 Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] BugDay - Saturday 4th October
Roy Bamford wrote: > It's that time of the month again, time for another BugDay on Saturday > 4th September. > Read all about it http://bugday.gentoo.org/ Maybe it would be a good idea to update that bugday page? Maybe devs could propose some bugs to be looked at? Maybe we could also ask users for suggestions, bugs that have been open for a while that they really want to see fixed? Also, I would like to ask for devs who are willing to work with proxy-maintainers. Maybe we could put up a list somewhere, so that users who are interested in doing proxy-maintenance know who to turn to. Thanks, -- Ben de Groot Gentoo Linux developer (lxde, media, desktop-misc) Gentoo Linux Release Engineering PR liaison __ [EMAIL PROTECTED] http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] BugDay - Saturday 4th October
Ben de Groot wrote: > Roy Bamford wrote: >> It's that time of the month again, time for another BugDay on Saturday >> 4th September. >> Read all about it http://bugday.gentoo.org/ > > Maybe it would be a good idea to update that bugday page? Maybe devs > could propose some bugs to be looked at? After the last bugday I had the idea on IRC about bugzilla BUGDAY keywords that devs would countinuously assign to bugs they see fit for buday and the page would list them automatically. Maybe more variants of the keyword to distinguish what the users should do (provide patch, test something...) or expected amount of skill from the users. The NeedPatch keyword could probably be used right away. What do you think? > Maybe we could also ask users > for suggestions, bugs that have been open for a while that they really > want to see fixed? We have voting, should promote it to be used more and also syndicate it somehow on the bugday page? > Also, I would like to ask for devs who are willing to work with > proxy-maintainers. Maybe we could put up a list somewhere, so that users > who are interested in doing proxy-maintenance know who to turn to. Good idea. Caster signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, Please consider a PROPERTIES=set value that allows an ebuild to indicate that it should behave like a package set when selected on the command line. This is behavior is somewhat difficult to describe in words but the following example should be sufficient to convey the general idea. Consider a case where all of the kde-base/*-meta packages exhibit the "set" property, and these packages and their dependencies are currently installed. In such a case, the default behavior for a command such as `emerge kde-base/kde-meta` should be to reinstall the the selected kde-base/kde-meta ebuild and the set of packages which includes it's direct dependencies and it's recursive "set" dependencies. So, assuming that all USE flags are enabled for the selected kde-base/kde-meta ebuild, it would reinstall the direct dependencies of kdeartwork-meta, kdebase-meta, kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta, kdenetwork-meta, kdetoys-meta, kdeutils-meta, and kdeaccessibility-meta ebuilds. Similarly, the default behavior for a command such as `emerge --unmerge kde-base/kde-meta` would be to uninstall the same set of packages. The advantage of using the PROPERTIES=set approach, rather than some alternative approach, is that the PROPERTIES=set approach fits nicely into the existing framework, similar to the way that "virtual" ebuilds [1] fit into the existing framework. For example, /etc/portage/package.use can be used to control the USE flags of these "set" ebuilds in the same way that it is currently used to control any other package. Also, tools that are designed to work with existing ebuilds will continue to work just as well with "set" ebuilds. Similar to the proposed "virtual" property [2], the "set" property will indicate that dependency calculations should consider the ebuild to have zero installation cost. Other than this, an ebuild which exhibits the "set" property should behave just like any other ebuild. It should be installed and uninstalled just like any other ebuild, including execution of all the normal ebuild phase functions that would be executed for any other ebuild that does not exhibit the "set" property. Does this seem like a good approach? Are there any suggestions for improvements or alternative approaches? [1] http://www.gentoo.org/proj/en/glep/glep-0037.html [2] http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjezf0ACgkQ/ejvha5XGaN78wCg3RHVdox0VaFq+241zVWRkNTH 6H8AoNNMw/I1bWPzM13yN2PMDg6+MTmD =dxEx -END PGP SIGNATURE-
