Re: [gentoo-dev] RFC: splitting virtual/
On Tue, 16 Aug 2011 01:51:27 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 01:29 AM, Michał Górny wrote: On Tue, 16 Aug 2011 01:10:48 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:40 AM, Michał Górny wrote: On Tue, 16 Aug 2011 00:26:41 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:01 AM, Micha? Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? Actually, since EAPI 4 we have default src_install, so it's possible to have ebuilds that have no defined phases but still install stuff. + empty SRC_URI? I guess something like the workdir fallback conditions in PMS. When you consider that live ebuilds can have empty SRC_URI and download things during src_unpack, it seems more sensible and simple to introduce PROPERTIES=live or something like it. That way, we'll have a simple boolean flag and won't have to make any fragile assumptions. Live ebuild have to redefine src_unpack() which makes DEFINED_PHASES!=-. Sure, but the fact that you have to check two variables like that and make these fragile assumptions makes it seem like we're building a fragile kludge rather than something that's really practical. And isn't a random PROPERTIES value more fragile? If someone uses it incorrectly, the results are undefined. With older PMs, results are undefined. While having empty SRC_URI and no DEFINED_PHASES guarantees that the ebuild won't install a file. That's just per-def, nothing can happen. And still I think implementing stuff like that is just an ugly hack instead of fixing the real issue. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On Tue, 16 Aug 2011 03:01:26 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 02:32 AM, Ciaran McCreesh wrote: On Tue, 16 Aug 2011 00:19:38 -0700 Zac Medico zmed...@gentoo.org wrote: Isn't that another, ugly, non-PMS hack which makes people think they are creating correct packages? Are you saying that you'd prefer to have package managers pull in redundant packages for not good reason? No, package managers should get things right regardless of whether something is in the 'virtual/' category or not. If they can't get things right, then we need to supply them with more data. Consider the virtual/jre and virtual/jdk case. Suppose that virtual/jdk isn't installed for some reason, but dev-java/sun-jdk which satisfies it is already installed. In this case, unless you know that virtual/jdk is zero-cost, it's not clear that it costs less to install virtual/jdk than to install dev-java/sun-jre-bin. There may be lots of cases like this where zero-cost metadata would be useful. Maybe virtual/jre virtual/jdk should me merged into a single ebuild with USE-switchable behavior? Something like: RDEPEND=jdk? ( || ( a-jdk b-jdk ) ) !jdk? ( || ( a-jre b-jre a-jdk b-jdk ) ) -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On Wed, 17 Aug 2011, Michał Górny wrote: And isn't a random PROPERTIES value more fragile? If someone uses it incorrectly, the results are undefined. With older PMs, results are undefined. While having empty SRC_URI and no DEFINED_PHASES guarantees that the ebuild won't install a file. That's just per-def, nothing can happen. Unfortunately, the inverse is not true. There are virtuals that define phase functions, see virtual/ruby-* for example. Ulrich
Re: [gentoo-dev] RFC: splitting virtual/
On 08/17/2011 12:20 AM, Michał Górny wrote: On Tue, 16 Aug 2011 03:01:26 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 02:32 AM, Ciaran McCreesh wrote: On Tue, 16 Aug 2011 00:19:38 -0700 Zac Medico zmed...@gentoo.org wrote: Isn't that another, ugly, non-PMS hack which makes people think they are creating correct packages? Are you saying that you'd prefer to have package managers pull in redundant packages for not good reason? No, package managers should get things right regardless of whether something is in the 'virtual/' category or not. If they can't get things right, then we need to supply them with more data. Consider the virtual/jre and virtual/jdk case. Suppose that virtual/jdk isn't installed for some reason, but dev-java/sun-jdk which satisfies it is already installed. In this case, unless you know that virtual/jdk is zero-cost, it's not clear that it costs less to install virtual/jdk than to install dev-java/sun-jre-bin. There may be lots of cases like this where zero-cost metadata would be useful. Maybe virtual/jre virtual/jdk should me merged into a single ebuild with USE-switchable behavior? Something like: RDEPEND=jdk? ( || ( a-jdk b-jdk ) ) !jdk? ( || ( a-jre b-jre a-jdk b-jdk ) ) Here it seems like you're introducing a USE flag in order to overcome a shortcoming of the dependency resolver. Note that the jre and jdk relationship isn't necessarily the only relationship with these properties. Wouldn't it be better to make the dependency resolver a bit smarter (as implemented in portage for many years), than to introduce a bunch of workarounds like the jdk USE flag that you suggest? -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On 08/17/2011 12:16 AM, Michał Górny wrote: On Tue, 16 Aug 2011 01:51:27 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 01:29 AM, Michał Górny wrote: On Tue, 16 Aug 2011 01:10:48 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:40 AM, Michał Górny wrote: On Tue, 16 Aug 2011 00:26:41 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:01 AM, Micha? Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? Actually, since EAPI 4 we have default src_install, so it's possible to have ebuilds that have no defined phases but still install stuff. + empty SRC_URI? I guess something like the workdir fallback conditions in PMS. When you consider that live ebuilds can have empty SRC_URI and download things during src_unpack, it seems more sensible and simple to introduce PROPERTIES=live or something like it. That way, we'll have a simple boolean flag and won't have to make any fragile assumptions. Live ebuild have to redefine src_unpack() which makes DEFINED_PHASES!=-. Sure, but the fact that you have to check two variables like that and make these fragile assumptions makes it seem like we're building a fragile kludge rather than something that's really practical. And isn't a random PROPERTIES value more fragile? Well, if we could have simply relied upon a single variable like DEFINED_PHASES, then that approach would have been preferable. But since it would require making fragile assumptions about DEFINED_PHASES and SRC_URI variables, I think PROPERTIES would be a much more practical approach. If someone uses it incorrectly, the results are undefined. I don't think it's a difficult concept to grasp, so I think it's unlikely to be used incorrectly. Even if it is used incorrectly, I don't see it causing major problems. With older PMs, results are undefined. The worst case is that some redundant packages are pulled into the dependency graph, which is the legacy behavior anyway, so there's no net loss. While having empty SRC_URI and no DEFINED_PHASES guarantees that the ebuild won't install a file. That's just per-def, nothing can happen. As Ulrich has already mentioned, virtual/ruby-* define phases, so your fragile assumptions are falling apart again. And still I think implementing stuff like that is just an ugly hack instead of fixing the real issue. Is the real issue that ebuild developers aren't using workarounds in order to overcome the shortcomings of some dependency resolvers? Really? -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On Wed, 17 Aug 2011 06:27:36 -0700 Zac Medico zmed...@gentoo.org wrote: Note that the jre and jdk relationship isn't necessarily the only relationship with these properties. Wouldn't it be better to make the dependency resolver a bit smarter (as implemented in portage for many years), than to introduce a bunch of workarounds like the jdk USE flag that you suggest? The dependency resolver can only be made smarter if it's given accurate information about when it can be smart. Random guesswork isn't accurate information. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On Wed, 17 Aug 2011 06:40:45 -0700 Zac Medico zmed...@gentoo.org wrote: Is the real issue that ebuild developers aren't using workarounds in order to overcome the shortcomings of some dependency resolvers? Really? The real issue is that Portage has nearly as much unspecified voodoo in its behaviour as a web browser. If you think there are particular cases where resolution should be smarter then the way to proceed is to introduce well-specified metadata to handle it -- and, importantly, you should *not* implement a dodgy workaround in the mean time. There shouldn't be any weird magical difference in behaviour based upon package name, and if something isn't done properly then it shouldn't be there at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On 08/17/2011 07:24 AM, Ciaran McCreesh wrote: On Wed, 17 Aug 2011 06:40:45 -0700 Zac Medico zmed...@gentoo.org wrote: Is the real issue that ebuild developers aren't using workarounds in order to overcome the shortcomings of some dependency resolvers? Really? The real issue is that Portage has nearly as much unspecified voodoo in its behaviour as a web browser. If you think there are particular cases where resolution should be smarter then the way to proceed is to introduce well-specified metadata to handle it Agreed. Obviously, I'm in favor of introducing this metadata that you speak of. -- and, importantly, you should *not* implement a dodgy workaround in the mean time. There shouldn't be any weird magical difference in behaviour based upon package name, and if something isn't done properly then it shouldn't be there at all. That's in the past now. Let's move forward with the introduction of the new metadata! -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On Wed, 17 Aug 2011 10:19:06 +0200 Ulrich Mueller u...@gentoo.org wrote: On Wed, 17 Aug 2011, Michał Górny wrote: And isn't a random PROPERTIES value more fragile? If someone uses it incorrectly, the results are undefined. With older PMs, results are undefined. While having empty SRC_URI and no DEFINED_PHASES guarantees that the ebuild won't install a file. That's just per-def, nothing can happen. Unfortunately, the inverse is not true. There are virtuals that define phase functions, see virtual/ruby-* for example. And that's another issue in the ebuild. It should be fixed so that phase functions won't be exported in the first place rather than redefining them. This way, PM could assume it doesn't need to execute those at all rather than running dummy code. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On 08/17/2011 10:03 AM, Michał Górny wrote: On Wed, 17 Aug 2011 10:19:06 +0200 Ulrich Mueller u...@gentoo.org wrote: On Wed, 17 Aug 2011, Michał Górny wrote: And isn't a random PROPERTIES value more fragile? If someone uses it incorrectly, the results are undefined. With older PMs, results are undefined. While having empty SRC_URI and no DEFINED_PHASES guarantees that the ebuild won't install a file. That's just per-def, nothing can happen. Unfortunately, the inverse is not true. There are virtuals that define phase functions, see virtual/ruby-* for example. And that's another issue in the ebuild. It should be fixed so that phase functions won't be exported in the first place rather than redefining them. This way, PM could assume it doesn't need to execute those at all rather than running dummy code. You can insist on this SRC_URI + DEFINED_PHASES approach, but I doubt that package manager developers will want to rely on these kinds of fragile assumptions. You thought that relying on the virtual category name was ridiculous, but this SRC_URI + DEFINED_PHASES approach seems must less practical to me. -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On Wed, 17 Aug 2011 10:58:32 -0700 Zac Medico zmed...@gentoo.org wrote: You can insist on this SRC_URI + DEFINED_PHASES approach, but I doubt that package manager developers will want to rely on these kinds of fragile assumptions. You thought that relying on the virtual category name was ridiculous, but this SRC_URI + DEFINED_PHASES approach seems must less practical to me. The difference is, SRC_URI + DEFINED_PHASES is guaranteed to work. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On Wed, 17 Aug 2011, Ciaran McCreesh wrote: On Wed, 17 Aug 2011 10:58:32 -0700 Zac Medico zmed...@gentoo.org wrote: You can insist on this SRC_URI + DEFINED_PHASES approach, but I doubt that package manager developers will want to rely on these kinds of fragile assumptions. You thought that relying on the virtual category name was ridiculous, but this SRC_URI + DEFINED_PHASES approach seems must less practical to me. The difference is, SRC_URI + DEFINED_PHASES is guaranteed to work. Adding explicit information to PROPERTIES still looks much cleaner to me. And as previously noted, not every virtual (or meta package) has empty DEFINED_PHASES. Ulrich
Re: [gentoo-dev] RFC: splitting virtual/
On Mon, 15 Aug 2011 19:42:01 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/15/2011 11:41 AM, Michał Górny wrote: Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. In sys-apps/portage, the virtual category is used as a hint to the dependency resolver it needs to look ahead in order to make the best possible choices. For example, in order to solve bug #141118 [1], it recursively expands virtual/jre and virtual/jdk in order to efficiently satisfy a jre dependency with whatever jdk happens to be installed, instead of pulling in a redundant jre. Isn't that another, ugly, non-PMS hack which makes people think they are creating correct packages? Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? [1] http://bugs.gentoo.org/show_bug.cgi?id=141118 [2] http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On 08/16/2011 12:01 AM, Michał Górny wrote: On Mon, 15 Aug 2011 19:42:01 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/15/2011 11:41 AM, Michał Górny wrote: Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. In sys-apps/portage, the virtual category is used as a hint to the dependency resolver it needs to look ahead in order to make the best possible choices. For example, in order to solve bug #141118 [1], it recursively expands virtual/jre and virtual/jdk in order to efficiently satisfy a jre dependency with whatever jdk happens to be installed, instead of pulling in a redundant jre. Isn't that another, ugly, non-PMS hack which makes people think they are creating correct packages? Are you saying that you'd prefer to have package managers pull in redundant packages for not good reason? Anyway, the thing that's really special about virtuals is that they can be considered to contribute zero-cost when the package manager is trying minimize the overall cost of satisfying a particular dependency. To minimize cost means to eliminate redundant packages. The relevance of virtuals in terms of cost calculations is why Ciaran suggested to call it PROPERTIES=zero-install-cost [1] instead of virtual. Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? That's an interesting idea. It seems like that should suffice for this purpose. [1] http://archives.gentoo.org/gentoo-dev/msg_47dc8f61c43d835c3feee77244188b02.xml -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/16/2011 12:01 AM, Micha? Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? Actually, since EAPI 4 we have default src_install, so it's possible to have ebuilds that have no defined phases but still install stuff. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5KG7EACgkQ/ejvha5XGaOIeACfSLRu2svBgk3zYi+bBD7HI6hP cjcAoJ2vqzeyXza8+p4FTlvK/Wjt6HXv =KlFM -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: splitting virtual/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 16 Aug 2011 00:26:41 -0700 Zac Medico zmed...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/16/2011 12:01 AM, Micha? Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? Actually, since EAPI 4 we have default src_install, so it's possible to have ebuilds that have no defined phases but still install stuff. + empty SRC_URI? I guess something like the workdir fallback conditions in PMS. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iJwEAQEIAAYFAk5KHv8ACgkQfXuS5UK5QB0PbgP9GupYR9x+mTGrLfGeGeNH5qE9 RfkK1N4lLyU+yaekwEVpAWlQlRfm7Fi/p7kjsDF9sOCQ3QHJhtLv2kCdDrwmucAr lnNKgz48bHn9CDc+zdBHlTox8ll93vwVEIxL5+gEgZK67RD6Z6Of+yVSrGJPVgQi UqSEvRk8HbyLD3Tdg8g= =jaP+ -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: splitting virtual/
On 08/16/2011 12:40 AM, Michał Górny wrote: On Tue, 16 Aug 2011 00:26:41 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:01 AM, Micha? Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? Actually, since EAPI 4 we have default src_install, so it's possible to have ebuilds that have no defined phases but still install stuff. + empty SRC_URI? I guess something like the workdir fallback conditions in PMS. When you consider that live ebuilds can have empty SRC_URI and download things during src_unpack, it seems more sensible and simple to introduce PROPERTIES=live or something like it. That way, we'll have a simple boolean flag and won't have to make any fragile assumptions. -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On Tue, 16 Aug 2011 01:10:48 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:40 AM, Michał Górny wrote: On Tue, 16 Aug 2011 00:26:41 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:01 AM, Micha? Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? Actually, since EAPI 4 we have default src_install, so it's possible to have ebuilds that have no defined phases but still install stuff. + empty SRC_URI? I guess something like the workdir fallback conditions in PMS. When you consider that live ebuilds can have empty SRC_URI and download things during src_unpack, it seems more sensible and simple to introduce PROPERTIES=live or something like it. That way, we'll have a simple boolean flag and won't have to make any fragile assumptions. Live ebuild have to redefine src_unpack() which makes DEFINED_PHASES!=-. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On 08/16/2011 01:29 AM, Michał Górny wrote: On Tue, 16 Aug 2011 01:10:48 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:40 AM, Michał Górny wrote: On Tue, 16 Aug 2011 00:26:41 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 12:01 AM, Micha? Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. Doesn't DEFINED_PHASES==- serve that purpose nowadays? Actually, since EAPI 4 we have default src_install, so it's possible to have ebuilds that have no defined phases but still install stuff. + empty SRC_URI? I guess something like the workdir fallback conditions in PMS. When you consider that live ebuilds can have empty SRC_URI and download things during src_unpack, it seems more sensible and simple to introduce PROPERTIES=live or something like it. That way, we'll have a simple boolean flag and won't have to make any fragile assumptions. Live ebuild have to redefine src_unpack() which makes DEFINED_PHASES!=-. Sure, but the fact that you have to check two variables like that and make these fragile assumptions makes it seem like we're building a fragile kludge rather than something that's really practical. -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On Tue, 16 Aug 2011 00:19:38 -0700 Zac Medico zmed...@gentoo.org wrote: Isn't that another, ugly, non-PMS hack which makes people think they are creating correct packages? Are you saying that you'd prefer to have package managers pull in redundant packages for not good reason? No, package managers should get things right regardless of whether something is in the 'virtual/' category or not. If they can't get things right, then we need to supply them with more data. And most importantly, you need to stop adding in short-sighted hacks to 'fix' one bug at the expense of consistency and quality. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On 08/16/2011 02:32 AM, Ciaran McCreesh wrote: On Tue, 16 Aug 2011 00:19:38 -0700 Zac Medico zmed...@gentoo.org wrote: Isn't that another, ugly, non-PMS hack which makes people think they are creating correct packages? Are you saying that you'd prefer to have package managers pull in redundant packages for not good reason? No, package managers should get things right regardless of whether something is in the 'virtual/' category or not. If they can't get things right, then we need to supply them with more data. Consider the virtual/jre and virtual/jdk case. Suppose that virtual/jdk isn't installed for some reason, but dev-java/sun-jdk which satisfies it is already installed. In this case, unless you know that virtual/jdk is zero-cost, it's not clear that it costs less to install virtual/jdk than to install dev-java/sun-jre-bin. There may be lots of cases like this where zero-cost metadata would be useful. And most importantly, you need to stop adding in short-sighted hacks to 'fix' one bug at the expense of consistency and quality. Call it what you want, but the behavior that I implemented for bug 141118 seems relatively optimal to me. -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On Tue, 16 Aug 2011 03:01:26 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/16/2011 02:32 AM, Ciaran McCreesh wrote: On Tue, 16 Aug 2011 00:19:38 -0700 Zac Medico zmed...@gentoo.org wrote: Isn't that another, ugly, non-PMS hack which makes people think they are creating correct packages? Are you saying that you'd prefer to have package managers pull in redundant packages for not good reason? No, package managers should get things right regardless of whether something is in the 'virtual/' category or not. If they can't get things right, then we need to supply them with more data. Consider the virtual/jre and virtual/jdk case. Suppose that virtual/jdk isn't installed for some reason, but dev-java/sun-jdk which satisfies it is already installed. In this case, unless you know that virtual/jdk is zero-cost, it's not clear that it costs less to install virtual/jdk than to install dev-java/sun-jre-bin. There may be lots of cases like this where zero-cost metadata would be useful. Uh huh, so rather than adding in a hack, we need a proper way of identifying those cases. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On Monday, August 15, 2011 17:33:24 Nirbheek Chauhan wrote: I don't see a pressing need to split virtual/ yet :) +1 -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] RFC: splitting virtual/
Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny mgo...@gentoo.org wrote: Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? why? -- Best regards, Michał Górny
Re: [gentoo-dev] RFC: splitting virtual/
On Mon, 15 Aug 2011 12:46:59 -0700 Alec Warner anta...@gentoo.org wrote: On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny mgo...@gentoo.org wrote: Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? why? Because I like categories much more than I do prefixes. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: splitting virtual/
On 08/15/11 21:55, Michał Górny wrote: On Mon, 15 Aug 2011 12:46:59 -0700 Alec Warner anta...@gentoo.org wrote: On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny mgo...@gentoo.org wrote: Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? why? Because I like categories much more than I do prefixes. But right now all virtuals are easily recognizable and nicely grouped into one category. From my point of view that's the best categorization we could ask for ... what would we gain from changing it?
Re: [gentoo-dev] RFC: splitting virtual/
On Tue, Aug 16, 2011 at 12:11 AM, Michał Górny mgo...@gentoo.org wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? $ ls -1 /usr/portage/virtual/ | wc -l 155 $ ls -1 /usr/portage/dev-libs/ | wc -l 370 $ ls -1 /usr/portage/net-libs/ | wc -l 135 $ ls -1 /usr/portage/dev-util/ | wc -l 278 $ ls -1 /usr/portage/dev-perl/ | wc -l 1029 I don't see a pressing need to split virtual/ yet :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: splitting virtual/
110815 Patrick Lauer wrote: On 08/15/11 21:55, Michał Górny wrote: Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? -- maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? right now all virtuals are easily recognizable and nicely grouped into one category. If you're going to take that route, which mb a small improvement, it sb 'virtual-perl', 'virtual-java' etc. It would help users see more clearly what sundry virtuals are for: the present size of the category is less important than clarity. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] RFC: splitting virtual/
On 08/15/2011 11:41 AM, Michał Górny wrote: Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. In sys-apps/portage, the virtual category is used as a hint to the dependency resolver it needs to look ahead in order to make the best possible choices. For example, in order to solve bug #141118 [1], it recursively expands virtual/jre and virtual/jdk in order to efficiently satisfy a jre dependency with whatever jdk happens to be installed, instead of pulling in a redundant jre. Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? If you're going to do that, then I'd suggest giving them some sort of tag that the package manager can rely upon in order to identify them as virtuals. For example, we could have the ebuilds set PROPERTIES=virtual [2], or we could simply specify (in PMS) that any category whose name matches the '*-virtual' pattern will contain virtuals. [1] http://bugs.gentoo.org/show_bug.cgi?id=141118 [2] http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml -- Thanks, Zac
Re: [gentoo-dev] RFC: splitting virtual/
On Mon, Aug 15, 2011 at 5:22 PM, Patrick Lauer patr...@gentoo.org wrote: On 08/15/11 21:55, Michał Górny wrote: On Mon, 15 Aug 2011 12:46:59 -0700 Alec Warner anta...@gentoo.org wrote: On Mon, Aug 15, 2011 at 11:41 AM, Michał Górny mgo...@gentoo.org wrote: Hello, Now that we don't have any old-style virtuals in gx86 anymore, I think the 'virtual' category is basically one another plain category nowadays. Considering the number of different virtuals in this category, maybe it would be a good idea to split it a little? What I'm proposing is maybe creating some kind of '*-virtual' categories. For example, half of the current virtuals are prefixed with 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? why? Because I like categories much more than I do prefixes. But right now all virtuals are easily recognizable and nicely grouped into one category. From my point of view that's the best categorization we could ask for ... what would we gain from changing it? Nothing IMO. +1 to keep virtuals as they are now. Regards, -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
