Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jorge, On Thu, 22 Jul 2010 18:04:59 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: If you want to use sqlite3 as default and assuming your prefer postgres over mysql, you can use the following and drop the die from pkg_setup. DEPEND= ... snip ... !bacula-clientonly? ( sqlite3? ( app-backup/bacula[-mysql.-postgres] dev-db/sqlite:3 ) !sqlite3? ( postgres? ( mysql? ( app-backup/bacula[-mysql] ) dev-db/postgresql-base[threads] ) !postgres? ( mysql? ( virtual/mysql ) !mysql? ( app-backup/bacula[sqlite3] ) ) !bacula-nodir? ( virtual/mta ) ) ... snip ... interesting. I did not know that an ebuild can use-depend on itself. Good to know. I had implemented a simpler solution in meantime. But I will test your solution. It would shorten the ebuild by a good amount (It is already much to big and complicated). Furthermore it catches the problems very early (before merging the wrong dependencies). Only downside I see is that the user has to find out why she gets the messages about the wrong USE flag requirements. Say, you want to build it with mysql and have 'sqlite' in make.conf your USE=mysql emerge bacula resultes in a emerge: there are no ebuilds built with USE flags to satisfy app-backup/bacula[-mysql,-postgres]. And than you have to think. Anyway I will think over it. Regards, Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJP2wACgkQQe4uqXYgU9XomwCfeFkb780NSjA0Q7eUCMDmGF0U 1kAAn2pJwIFXbBF0t6gN0eosBxv5c3f4 =jy0D -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 23.7.2010 09:06, Thomas Beierlein napsal(a): Hi Jorge, interesting. I did not know that an ebuild can use-depend on itself. Good to know. I had implemented a simpler solution in meantime. But I will test your solution. It would shorten the ebuild by a good amount (It is already much to big and complicated). Furthermore it catches the problems very early (before merging the wrong dependencies). Only downside I see is that the user has to find out why she gets the messages about the wrong USE flag requirements. Say, you want to build it with mysql and have 'sqlite' in make.conf your USE=mysql emerge bacula resultes in a emerge: there are no ebuilds built with USE flags to satisfy app-backup/bacula[-mysql,-postgres]. And than you have to think. Anyway I will think over it. Regards, Thomas. So I will help with my 2c :P I reworked the bacula for the purposes at my company: http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=blob;f=app-backup/bacula/bacula-3.0.3.ebuild I implemented most things people complain here, so might be really really smart to just copy the parts. Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxJVR8ACgkQHB6c3gNBRYfDmACfXGtiijVHHMZKDSvuXpHjpAe9 gloAoMw/lTI6TvW+rt4+eXYakcaRu2Dw =AaHp -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
Am Freitag, den 23.07.2010, 09:06 +0200 schrieb Thomas Beierlein: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jorge, On Thu, 22 Jul 2010 18:04:59 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: If you want to use sqlite3 as default and assuming your prefer postgres over mysql, you can use the following and drop the die from pkg_setup. DEPEND= ... snip ... !bacula-clientonly? ( sqlite3? ( app-backup/bacula[-mysql.-postgres] dev-db/sqlite:3 ) !sqlite3? ( postgres? ( mysql? ( app-backup/bacula[-mysql] ) dev-db/postgresql-base[threads] ) !postgres? ( mysql? ( virtual/mysql ) !mysql? ( app-backup/bacula[sqlite3] ) ) !bacula-nodir? ( virtual/mta ) ) ... snip ... interesting. I did not know that an ebuild can use-depend on itself. Good to know. No, not good. It doesn't make any sense. We will have a solution for such cases somewhere in the future, but at the moment you should just display a warning that even though the user specified more than one db only is going to be used. Cheers, Tiziano -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2010 11:31:30 +0200 Tiziano Müller dev-z...@gentoo.org wrote: Am Freitag, den 23.07.2010, 09:06 +0200 schrieb Thomas Beierlein: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jorge, On Thu, 22 Jul 2010 18:04:59 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: If you want to use sqlite3 as default and assuming your prefer postgres over mysql, you can use the following and drop the die from pkg_setup. DEPEND= ... snip ... !bacula-clientonly? ( sqlite3? ( app-backup/bacula[-mysql.-postgres] dev-db/sqlite:3 ) !sqlite3? ( postgres? ( mysql? ( app-backup/bacula[-mysql] ) dev-db/postgresql-base[threads] ) !postgres? ( mysql? ( virtual/mysql ) !mysql? ( app-backup/bacula[sqlite3] ) ) !bacula-nodir? ( virtual/mta ) ) ... snip ... interesting. I did not know that an ebuild can use-depend on itself. Good to know. No, not good. It doesn't make any sense. Can you give some reasoning for that? We will have a solution for such cases somewhere in the future, but at the moment you should just display a warning that even though the user specified more than one db only is going to be used. That is what I am doing at the moment. If 0 or more than one backends are selected I fall back to sqlite3 as default and give an according warning message. Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJfUkACgkQQe4uqXYgU9WW7QCbBYthd11EnPrtVJf4RXTqUMVT q9UAoJ//DyXGQmlFLmU4EM3knn6wv98W =CsP/ -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2010 13:30:02 +0200 Thomas Beierlein tom...@gentoo.org wrote: interesting. I did not know that an ebuild can use-depend on itself. Good to know. No, not good. It doesn't make any sense. Can you give some reasoning for that? It's entirely unclear what deps upon self actually mean. Some people use them to say that a package needs to be installed before it can install itself. Thus, things like: DEPEND=|| ( myself myself-bin ) So a dependency upon myself[foo] would probably mean I need myself[foo] to be installed before I can install myself, not I need the foo flag to be set on myself. In any case, abusing DEPEND isn't a mechanism for implementing use requirements. You should use the mechanism that's designed for use requirements to do use requirements, which means waiting for EAPI 4 and pkg_pretend, or just follow existing policy and pick one in the case of a conflict. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJfxcACgkQ96zL6DUtXhGXkQCcDzxMWkqm+ShdOEBOWH0nQJtE q0gAn0TRU7BtLVyKib6YJLNWtjjWoNFk =uYQb -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2010 10:38:56 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: So I will help with my 2c :P I reworked the bacula for the purposes at my company: http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=blob;f=app-backup/bacula/bacula-3.0.3.ebuild I implemented most things people complain here, so might be really really smart to just copy the parts. Cheers Tom Thanks for the link Tomáš. I am sure I will do some cherry pickings :). I agree with you that we need a better set of use flags, as you did in your in-house solution. The actual set is quite a pain. Let us see how we can switch to such a new set (like yours or similar). I was thinking about an accompanying news item, but not before the next release of a new bacula version. That gives some time for preparation and a chance for thorough tests. I am still not sure why some of the old features gets dropped starting with bacula-5.0.1. I asked the former maintainer, but got no response at all. So any ideas are welcome. Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJhqoACgkQQe4uqXYgU9WdMwCgq20FoE1FqjlPaMYF7QmXEmHX BKoAnRH5QAzkvIzln6Mylj4Xyh8nLJp9 =5aGB -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-07-2010 09:31, Tiziano Müller wrote: Am Freitag, den 23.07.2010, 09:06 +0200 schrieb Thomas Beierlein: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jorge, On Thu, 22 Jul 2010 18:04:59 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: If you want to use sqlite3 as default and assuming your prefer postgres over mysql, you can use the following and drop the die from pkg_setup. DEPEND= ... snip ... !bacula-clientonly? ( sqlite3? ( app-backup/bacula[-mysql.-postgres] dev-db/sqlite:3 ) !sqlite3? ( postgres? ( mysql? ( app-backup/bacula[-mysql] ) dev-db/postgresql-base[threads] ) !postgres? ( mysql? ( virtual/mysql ) !mysql? ( app-backup/bacula[sqlite3] ) ) !bacula-nodir? ( virtual/mta ) ) ... snip ... interesting. I did not know that an ebuild can use-depend on itself. Good to know. No, not good. It doesn't make any sense. You may not like it, but saying it doesn't make sense is wrong. It does make sense and ensures what Tom was trying to get and is already being used in the tree. We will have a solution for such cases somewhere in the future, but at the moment you should just display a warning that even though the user specified more than one db only is going to be used. Nothing prevents us from using the above, which already produces the same output as basic use dependencies, so users should be getting used to it by now. It would be great if PMs could produce more detailed warnings to the user, but that can wait (may have to wait?) for the new solutions. Cheers, Tiziano - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMSYrlAAoJEC8ZTXQF1qEPW7oP/0Ct9gGS3xeFjkX1EI2PwkL6 uu9ZMQOnKIrfeWkmN3XCtTB/CHoBKLQlnspiOh47O3Rm+dsOcaWg+sjTp+4UJqO9 ldTjEltcEbAk7PdpVceg4c3vvXJBsVyVWCYY2tXCQA7MQMamLZ12GxaqfB9un+hl BuqUwqdvLaZ3EFkOyZR4UfSGd4sRPGaTQjHGtk0/P8LJXOy9RjfMPCYTfyKuSuHG B0OU5y+GPcjEQtfkIDCQpUoKH/K3IhIwlkNGd9+nmS+x1ny9GZ0XSr4YiR+lVpLq TU2iHW75HFJa6g0f4HGE01gwRfYy7QX9EZsjenrEiN6dkvI2BOIB92VWXj9Y5Ppa ZBQey9MfQ7m26V4fJtlzM+PP25uJkIJLHBTPlrE44xuCWxMwKXjtGcFGrAkn1Uof xJC94OhzGglcGxBcj8oKNRsdLPcPSajctbZgnxyLMUYpQhpQ2tAg7/loH1MUdbOE rj943cw4kucHSz/AOBMZVV1nOdqnSvuO7WnbTxjynxe4wDzI+66bg7pEtFfqXaO+ rMPGhp6kUl29j7SIQnGzNcZCOZ4Dm/MXW4BQygFYkVZUsz+AFkCR3AZocrkMMpD2 dXJfn9QHsVaN8t8crYGLI6ya9M+bXYb5yh9O2QEmmJrIHbSweHGeb/nwAs+BtMJH Gig3dsa7gH19pNYRBoKP =zddJ -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-07-2010 11:37, Ciaran McCreesh wrote: On Fri, 23 Jul 2010 13:30:02 +0200 Thomas Beierlein tom...@gentoo.org wrote: interesting. I did not know that an ebuild can use-depend on itself. Good to know. No, not good. It doesn't make any sense. Can you give some reasoning for that? It's entirely unclear what deps upon self actually mean. Some people use them to say that a package needs to be installed before it can install itself. Thus, things like: DEPEND=|| ( myself myself-bin ) So a dependency upon myself[foo] would probably mean I need myself[foo] to be installed before I can install myself, not I need the foo flag to be set on myself. In this case the dependencies are clear. They're not pretty, but they're clear. In any case, abusing DEPEND isn't a mechanism for implementing use requirements. You should use the mechanism that's designed for use requirements to do use requirements, which means waiting for EAPI 4 and pkg_pretend, or just follow existing policy and pick one in the case of a conflict. Abusing depend is a good way to do this, until we get better tools. I have to agree with Brian's proposal and say that in this particular case, the best solution is required_use and not pkg_pretend. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMSYtrAAoJEC8ZTXQF1qEPERoQAL6mZOy0q7SnJO1+7ykRCvSa sUTsb1sKwSi9XMAGeKGdwMZ6+8y9sbaidqlAyCcp+EOFRlUP2eXb+fZVgHCWSjRn VXEVBz3sYf/9VY8S2JF56MifJcysv9QePrf9dtm0VtbsD/lAlTBBVW2xM4AUJITB kZLaDTTWBh3KaK57EYkeT0cSzhB2wkmFo5uBvoTl3Gjefsdvx9pQwA3/W9BJl7YY XnxdXjSzVKw0t382dyoOvyNhRjnYN6eMnHKhLwUt1k7p1AmQLDIZso02IF1GpzwZ YVwMMogvBkAbJvFnwl+Vc/nQIsydYeYoQi5KDxVbQn3Dgmn7+i3yjfkGpCv2nHLQ QOBOlzxdx5cGxS1cQFM0//ugR16WWisfHn7d9X9kPlwvE516x14Pqig//cATh/Jk mbuvICHeUnxDzBnrWH4Z5QjRQhwtA/3dlK7M0k78PFgVjzChS+2o9w8jNNdjhp1+ oFj650hLrG3tpATZwLdKJViRo75Em+Mi+18z4BbwAhoL5VdeDPOxPYT8JemnLD2i 2f5hGvPcnAHJmlMkT00PpTR5BZZ4o6Kw69pqA0gYSP2pvDOtmqXVlEeJlhYpv57j bAgPXiG0DVlNkfPf9g+wVzcbFUYob7xGAG0IlDHU7S4IfIX+JzlfsFsskashH8of K7zcCISFebd/uD59cRPB =6TgE -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2010 12:30:35 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: In any case, abusing DEPEND isn't a mechanism for implementing use requirements. You should use the mechanism that's designed for use requirements to do use requirements, which means waiting for EAPI 4 and pkg_pretend, or just follow existing policy and pick one in the case of a conflict. Abusing depend is a good way to do this, until we get better tools. No, it's not, because it doesn't work. Assuming self deps are legal in the || ( myself myself-bin ) case, they can't do what you want for use requirements. myself[foo] would be met when building with USE=-foo so long as myself[foo] was installed originally, and it wouldn't be met unless myself were already installed. I have to agree with Brian's proposal and say that in this particular case, the best solution is required_use and not pkg_pretend. required_use may theoretically allow a package manager to do cycle breaking if all the relevant packages are updated to export information about which flags are and are not safe to toggle, but since no-one's proposed exporting that information or has even worked out exactly what the requirements would be for that to happen, and since pkg_pretend is required anyway for other things, just going with pkg_pretend for now is the sensible solution. Of course, this is all irrelevant since at the current rate of progress Portage is two years off any of this being available for developers anyway... - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJjWoACgkQ96zL6DUtXhEpzQCfWxZS/6t+U+5n/ASlR4cUbC07 ofkAoMTbjrwE3d19xaapxcB58eEJn3qX =F3XH -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2010 12:28:21 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: Nothing prevents us from using the above, which already produces the same output as basic use dependencies, so users should be getting used to it by now. It would be great if PMs could produce more detailed warnings to the user, but that can wait (may have to wait?) for the new solutions. If it does, it's a bug in Portage. If you've got foo[bar] installed, and the user tries to install foo[-bar], and foo[bar] DEPENDs upon foo[bar], that has to be allowed as a generalisation of handling || ( foo foo-bin ). Conversely, if foo isn't installed at all, then foo[bar] as a dependency must not be met even if the user is installing foo[bar]. Dependencies on self must match the previously installed package, not the thing being installed at the time. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJjn4ACgkQ96zL6DUtXhG4UgCfQ09rlDbVEAAFDYHr4mQQJzjb ke4AoIPCUwAOl38RHW6aUcAhwihxjEid =4Wrl -END PGP SIGNATURE-
Re: [gentoo-dev] Re: New global USE flag: introspection
On Tuesday 22 of June 2010 19:14:38 Arun Raghavan wrote:
On 20 June 2010 20:12, Arun Raghavan ford_pref...@gentoo.org wrote:
[...]
Any objections? I'll wait till Wed (June 23rd) before adding this if
there aren't any.
Is anyone here vehemently against introspection.
Not vehemently, but how would you differentiate between gobject introspection
or (let's say) DBus introspection or Kross (if anyone writes one).
'introspection' global USE flag simply cannot be described as:
Use pkgdev-libs/gobject-introspection/pkg for introspection/flag
because the term introspection is not specific to GObject. Period.
Now, I don't want to sound harsh, but I understand in Gnome camp (upstream)
there's a tendency to use commonly used names for Gnome specific
technologies. For instance - there's WebKitGtk but tarballs is called (yes,
you guessed it) - webkit-${PV}.tar.gz. It's like for many Desktop Environment
means Gnome, Linux means Ubuntu and such.
The same applies to GObject introspection - in autotools there's --enable-
introspection switch for it like the term introspection was exclusive for
GObject. Also many upstream developers working with Gnome/Gtk/Glib libs and
using said GObject introspection will defend their right to hijack this term
(like certain developer of a library I maintain in Gentoo).
I'd prefer not to see such practice here.
I'd suggest gobject-introspection USE flag instead - it's self describing.
If 'introspection' USE flag is to be used globally, it needs to have
description implementation-agnostic, let's say:
Enable runtime API introspection
or something like this.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
