Re: [gentoo-dev] New eclass: go-mono.eclass
Peter Alfredsen wrote:
Below is a copy of the eclass I intend to use for all apps from
go-mono.com (AKA mono-project.com). Pretty standard fare. The affected
ebuilds are:
www-apache/mod_mono
dev-dotnet/xsp
dev-dotnet/libgdiplus
dev-dotnet/gluezilla
dev-lang/mono
dev-lang/mono-basic
dev-util/mono-debugger
dev-util/mono-tools
I'll be committing it tomorrow together with version 2.2 of the mono
stack unless anybody has a good reason not to.
# @FUNCTION: go-mono_src_unpack
# @DESCRIPTION: Runs default()
go-mono_src_unpack() {
default
}
What's the point? The ones from base.eclass should be doing the same
thing as the default ones any way.
The same goes for src_compile.
local COMMONDOC=( AUTHORS ChangeLog README TODO )
I wouldn't write local variables with capital letters.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass: go-mono.eclass
On Sat, 17 Jan 2009 14:04:28 +0200
Petteri Räty betelge...@gentoo.org wrote:
# @FUNCTION: go-mono_src_unpack
# @DESCRIPTION: Runs default()
go-mono_src_unpack() {
default
}
What's the point? The ones from base.eclass should be doing the same
thing as the default ones any way.
The same goes for src_compile.
To make sure we know what we are getting and don't have to go searching
through more than one eclass to see exactly what a function does.
local COMMONDOC=( AUTHORS ChangeLog README TODO )
I wouldn't write local variables with capital letters.
Sure, we can paint the bikeshed green :-)
/PA
[gentoo-dev] RDEPEND definition in docs differ from official PMS specs
Hi, as specified in the PMS spec [1] and stated in #gentoo-portage, RDEPEND will be set to DEPEND, if it is not defined in the ebuild itself. But devmanual [2] and developer handbook [3] both state, you have do explicitly set RDEPEND because it may be removed in the future. Since package manager have to follow the PMS spec, i would suggest to change those docs [2][3] and let them follow the PMS spec. Any problems, suggestions or anything else about this? [1]: http://dev.gentoo.org/~yngwin/pms/pms.html#x1-750008.4 [2]: http://devmanual.gentoo.org/general-concepts/dependencies/index.html [3]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1#doc_chap5 -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
Thomas Sachau wrote: as specified in the PMS spec [1] and stated in #gentoo-portage, RDEPEND will be set to DEPEND, if it is not defined in the ebuild itself. But devmanual [2] and developer handbook [3] both state, you have do explicitly set RDEPEND because it may be removed in the future. Please file a bug for devrel (the devrel handbook) and QA (for devmanual). Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New eclass: go-mono.eclass
Hi Peter.
NO_MONO_DEPEND=(
dev-lang/mono
dev-dotnet/libgdiplus
dev-dotnet/gluezilla
)
Just curious. What are the reasons to use array here?
go-mono_src_install () {
emake -j1 DESTDIR=${D} install || die install failed
Is parallel make broken everywhere? :O This is real pain since smp
systems became much more common these days.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] New eclass: go-mono.eclass
On Sat, 17 Jan 2009 16:31:30 +0300
Peter Volkov p...@gentoo.org wrote:
Hi Peter.
NO_MONO_DEPEND=(
dev-lang/mono
dev-dotnet/libgdiplus
dev-dotnet/gluezilla
)
Just curious. What are the reasons to use array here?
I try to use arrays as often as possible, so I don't have to worry
about the shortcomings of variables. In the above example, you're
correct that there's no reason to use them over variables.
go-mono_src_install () {
emake -j1 DESTDIR=${D} install || die install failed
Is parallel make broken everywhere? :O This is real pain since smp
systems became much more common these days.
It's only the install phase, and yes, it's generally broken. But that's
not really newsworthy, is it?
/PA
BTW
--jobs combined with --load-average rocks for smp systems. Total system
rebuild of 1200 packages in 12 hours.
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sat, 17 Jan 2009 14:09:49 +0100 Thomas Sachau to...@gentoo.org wrote: Hi, as specified in the PMS spec [1] and stated in #gentoo-portage, RDEPEND will be set to DEPEND, if it is not defined in the ebuild itself. But devmanual [2] and developer handbook [3] both state, you have do explicitly set RDEPEND because it may be removed in the future. Since package manager have to follow the PMS spec, i would suggest to change those docs [2][3] and let them follow the PMS spec. Any problems, suggestions or anything else about this? It's strongly recommended to set both explicitly as the behavior could change in future EAPI versions, and to ensure that you actually think about which deps are build deps and which are runtime deps. Also there is nothing wrong with policies being stricter than the underlying spec. Marius
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
Marius Mauch schrieb: On Sat, 17 Jan 2009 14:09:49 +0100 Thomas Sachau to...@gentoo.org wrote: Hi, as specified in the PMS spec [1] and stated in #gentoo-portage, RDEPEND will be set to DEPEND, if it is not defined in the ebuild itself. But devmanual [2] and developer handbook [3] both state, you have do explicitly set RDEPEND because it may be removed in the future. Since package manager have to follow the PMS spec, i would suggest to change those docs [2][3] and let them follow the PMS spec. Any problems, suggestions or anything else about this? It's strongly recommended to set both explicitly as the behavior could change in future EAPI versions, and to ensure that you actually think about which deps are build deps and which are runtime deps. Also there is nothing wrong with policies being stricter than the underlying spec. Marius If i want to use some future EAPI (give me some reasons, why this should be changed there by default), i should think about it. But most ebuilds will stay with the default. I do think about runtime deps and build deps. In my eyes, this is similar to src_unpack and src_compile. They have defaults, noone specifies the defaults, even if they are changed in some EAPI. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
El sáb, 17-01-2009 a las 16:41 +0100, Thomas Sachau escribió: Marius Mauch schrieb: On Sat, 17 Jan 2009 14:09:49 +0100 Thomas Sachau to...@gentoo.org wrote: Hi, as specified in the PMS spec [1] and stated in #gentoo-portage, RDEPEND will be set to DEPEND, if it is not defined in the ebuild itself. But devmanual [2] and developer handbook [3] both state, you have do explicitly set RDEPEND because it may be removed in the future. Since package manager have to follow the PMS spec, i would suggest to change those docs [2][3] and let them follow the PMS spec. Any problems, suggestions or anything else about this? It's strongly recommended to set both explicitly as the behavior could change in future EAPI versions, and to ensure that you actually think about which deps are build deps and which are runtime deps. Also there is nothing wrong with policies being stricter than the underlying spec. Marius If i want to use some future EAPI (give me some reasons, why this should be changed there by default), i should think about it. But most ebuilds will stay with the default. I do think about runtime deps and build deps. In my eyes, this is similar to src_unpack and src_compile. They have defaults, noone specifies the defaults, even if they are changed in some EAPI. You may want to change the wording in docs to make it say it's encouraged to set both but it's not technically needed. Note that PMS is *not* a good practice guidelenes. There are a bunch of things that are technically valid but wrong from a QA point of view. Regards, -- Santiago Moisés Mola Jabber: cooldw...@gmail.com | GPG: AAD203B5 signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sat, 17 Jan 2009 16:41:25 +0100 Thomas Sachau to...@gentoo.org wrote: Marius Mauch schrieb: It's strongly recommended to set both explicitly as the behavior could change in future EAPI versions, and to ensure that you actually think about which deps are build deps and which are runtime deps. Also there is nothing wrong with policies being stricter than the underlying spec. If i want to use some future EAPI (give me some reasons, why this should be changed there by default), i should think about it. If nothing else, dropping the implicit assignment would remove one special case to handle in the PM (and I hope that everyone agrees that special cases should generally be avoided). In the past there have also been some issues due to the interaction between the implicit setting of RDEPEND and eclasses (long fixed, but shows that there is a bit more involved than might obvious). But most ebuilds will stay with the default. I do think about runtime deps and build deps. If you do that's good, but that doesn't mean everyone else does. Consider looking at an ebuild for a package you're not familiar with that doesn't set RDEPEND. Could mean that the author was just too lazy to add a RDEPEND=$DEPEND statement and that all deps are needed for build and runtime, or that he completely forgot to think about runtime deps. There is no way to know (without asking him) if the implicit RDEPEND is actually intended or not. In my eyes, this is similar to src_unpack and src_compile. They have defaults, noone specifies the defaults, even if they are changed in some EAPI. Sure, but the key difference is that the defaults for those are fixed. You would have a point if the default src_compile would vary based on what other phase functions the ebuild defines, but that's not the case. Marius
Re: [gentoo-dev] Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson schrieb:
I'm raising this as an extension of bug 253076, but also because I see
the potential for danger.
To date, for an init script that has baselayout2-specific behavior, we
have had some variant of [ -e /lib/librc.so ] in the init script.
On a multilib profile with no symlinks and a 64-bit userspace, the .so
file would be installed in /lib64/librc.so, and the check would
mistakenly have the wrong result.
There's one fix that has started to turn up already, but I'm not sure if
it's going to be safe always: [ -f /etc/init.d/sysfs ]
This happens to work as openrc installs that init script.
As a long term solution, can we just consume an inode and have some file
like /etc/baselayout2? The file must reside on the / partition even when
the major trees /usr, /var, /tmp, /opt, /boot, /home, /dev, /root are
separate mountpoints.
Using a file in /etc would break if someone would downgrade from
baselayout2/openrc to baselayout1.
Why not teach /sbin/runscript it's own version? With something like this
we could also do stuff depending on a specific version of openrc:
- --- src/rc/runscript.c
+++ src/rc/runscript.c
@@ -1244,6 +1244,7 @@ runscript(int argc, char **argv)
setenv(EINFO_LOG, service, 1);
setenv(RC_SVCNAME, applet, 1);
+ setenv(OPENRC_VERSION, 0.4.2, 1);
/* Set an env var so that we always know our pid regardless of
any
subshells the init script may create so that our mark_service_*
and in the ebuild:
[ -n ${OPENRC_VERSION} ]
Affected and broken profiles:
- amd64's 2005.0/no-symlink (it was very widely deployed. It's not
supported or in the tree anymore, but there ARE still people using it)
- default/linux/sparc/2008.0 (unconfirmed)
That one should be fine. It has a pure 32bit userland, no lib64 or
lib32, just plain lib as libdir.
- Any profile that sets SYMLINK_LIB=no AND the userspace is 64-bit.
- Wouldn't surprise me if some of the N32 style mips stuff was broken
too.
Affected, but not broken profiles:
These are multilib, but with the default as 32-bit causes the lib to be
in right place.
- arch/powerpc/ppc64/32ul
- hardened/linux/powerpc/ppc64/2008.0/32bit-userland
- Any other profile that inherits features/32bit-userland
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklybyAACgkQknxn9PmJ76VL5QCfXLgKLtrObX2FzbQ3XMHhAqZi
nT8An1zTWYJSmdRs30eLfDIy4LpqslRp
=80mR
-END PGP SIGNATURE-
Re: [gentoo-dev] GLI Officially Deprecated
On Wed, 2009-01-14 at 17:05 +, Mike Auty wrote: I realize it might be a bit obvious to us, but from reading it people might wonder how they're supposed to carry out installs now. When the notice finally goes out, it might be worth mentioning that just the LiveCDs are no longer supported, and mention how often the install media is produced, and basically how people should go about doing installs these days. It's so easy to misread these things and for people to start pushing out blogs and articles saying Gentoo's stopped producing release media, etc, etc... +1 -- Arun signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Detecting Baselayout2/openrc - no-symlink profiles leading to breakage
Friedrich Oslage blueb...@gentoo.org posted 49726f21.8010...@gentoo.org, excerpted below, on Sun, 18 Jan 2009 00:52:01 +0100: Why not teach /sbin/runscript it's own version? With something like this we could also do stuff depending on a specific version of openrc: I happened to read the OP right before I headed in to work today, and thus had some time to think it over. This was the exact same idea I came up with and was going to post it if someone hadn't, when I got back. You beat me to it! =:^) In fact, if Roy hasn't instituted something like this already upstream, I'd be surprised if he doesn't take the idea and run with it as well, as it's certainly convenient functionality to have and expose, and I can think of all sorts of reasons it might come in handy and no reason not to do it. -- 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
