Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
Marius Mauch schrieb: It's strongly recommended to set both explicitly FYI, I've opened bug to add repoman check for this: http://bugs.gentoo.org/show_bug.cgi?id=255358 /me also had feeling that it's good idea to rely on implicit RDEPEND and since it's not true, it's better to warn developers about that. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
Peter Volkov wrote: Marius Mauch schrieb: It's strongly recommended to set both explicitly FYI, I've opened bug to add repoman check for this: http://bugs.gentoo.org/show_bug.cgi?id=255358 /me also had feeling that it's good idea to rely on implicit RDEPEND and since it's not true, it's better to warn developers about that. One thing to note why it's bad to rely on it is that if you have an eclass setting RDEPEND then you are probably not getting what you wanted. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sun, 18 Jan 2009 13:21:55 +0200 Petteri Räty betelge...@gentoo.org wrote: One thing to note why it's bad to rely on it is that if you have an eclass setting RDEPEND then you are probably not getting what you wanted. Actually, you do. If you have ebuild: DEPEND=from/ebuild and eclass: DEPEND=from/eclass RDEPEND=also-from/eclass you end up with: DEPEND=from/ebuild from/eclass RDEPEND=from/ebuild also-from/eclass It's been that way for several years now. And yes, I'd really like to see this killed for EAPI 3. Ideally we'd go with a single DEPENDENCIES variable with labels of some kind, something like: DEPENDENCIES= build: foo/bar build+run: foo/baz post: foo/plugin which would make it much easier to start specifying dependencies for use of ROOT properly in the future -- it'd just be new labels, not zillions of new variables. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sunday 18 of January 2009 16:21:57 Ciaran McCreesh wrote:
And yes, I'd really like to see this killed for EAPI 3. Ideally we'd go
with a single DEPENDENCIES variable with labels of some kind,
something like:
DEPENDENCIES=
build:
foo/bar
build+run:
foo/baz
post:
foo/plugin
which would make it much easier to start specifying dependencies for
use of ROOT properly in the future -- it'd just be new labels, not
zillions of new variables.
What's the benefit of changing syntax so dramatically? (apart from the sake of
changing it to someone's liking) and what's so wrong with zillion of separate
dependency variables? Are they too easy to read, implement and understand?
As everyone knows, to avoid copypaste one can easily use such scheme:
COMMONDEPEND=
somedep
someotherdep
someuse? ( conddep )
DEPEND=${COMMONDEPEND}
somebuilddeponly
RDEPEND=${COMMONDEPEND}
someruntimedeponly
Similar simple bash play can be used for other purposes as well.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sun, 18 Jan 2009 22:01:54 +0100 Maciej Mrozowski reave...@poczta.fm wrote: What's the benefit of changing syntax so dramatically? (apart from the sake of changing it to someone's liking) and what's so wrong with zillion of separate dependency variables? Are they too easy to read, implement and understand? As everyone knows, to avoid copypaste one can easily use such scheme: A zillion is a lot, and the whole cache and metadata mechanism can't deal with it. Start multiplying this lot together: * on / vs under ROOT/ * native vs target * required for build, run time, post, install, test or use * however many userland ABIs there are * however many Python ABIs there are It quickly becomes clear that various things that are wanted in the future can't be done by having lots of variables. -- Ciaran McCreesh signature.asc Description: PGP 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] 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
