Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, Dec 7, 2013 at 12:52 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: 2.) having dhcpcd in this list will cause everything else to be cleaned out that that is bd. imho, dhcpcd shouldn't be on this list at all purely from a safety perspective. The stages will have dhcpcd so they wouldn't end up with netifrc afaict. The problem is that dhcpcd can be used either as a network manager, or as a utility employed by a network manager. I'm not sure how use deps in virtuals work - if you could make the dependency on dhcpcd[network-manager] and not have portage try to get the user to change the config of dhcpcd if something else on the list is installed. The use flag wouldn't do anything, it would just be a message to portage that you intend to use dhcpcd as the network manager. But you could just as easily have the user do all of this manually - we don't have a kernel virtual to try to get the user to install a kernel. Honestly, I'm not really sure why anyone would want to make stage3 less functional than it already is but honestly net isn't something I'm ready to give up just yet. It isn't about making the stage3 less functional, but about giving the user a choice. We don't stick a kernel in stage3, despite the fact that everybody needs one. We don't stick an MTA in the stage3 despite the fact that one of those is pretty hard to live without. Now that Gentoo apparently offers a wide selection of network managers, perhaps it makes sense to have the user pick which one they want to use. IMHO the purpose of @system and the stage3 is to solve the circular dependency problem inherent in bootstrapping. It really shouldn't contain anything beyond this. By all means have an @useful-utils set or some kind of profile that auto-installs a list of packages like openssh, vim, and so on. However, these are not required to bootstrap a system and I'm not sure why we should be forcing them into the @system set as a result. Another option would be to have things installed in the stage3 that are not part of the @system set, so that they would be depcleaned at a later date. I'm not a big fan of that, however, mainly because it could be a curve-ball for somebody to deal with after they think they've gotten everything working. I think users will have a better understanding of how their system is set up if they put things there than if things start out there but get yanked out from under them. Rich
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2013 07:42 AM, Rich Freeman wrote: Honestly, I'm not really sure why anyone would want to make stage3 less functional than it already is but honestly net isn't something I'm ready to give up just yet. It isn't about making the stage3 less functional, but about giving the user a choice. We don't stick a kernel in stage3, despite the fact that everybody needs one. We don't stick an MTA in the stage3 despite the fact that one of those is pretty hard to live without. Now that Gentoo apparently offers a wide selection of network managers, perhaps it makes sense to have the user pick which one they want to use. Choice is fine, I love choice, but to have a user unpack a stage tarball and find no way at all to handle their networking that's just ugly. I mean we could just have dhcpcd in @system and let people figure it out from there (wouldn't be my first choice but it would work) but I would say it is rare enough to not need net that removing all networking options from stage3 is near suicidal. I can do all kinds of amazing things on a system without an MTA. But if I have no net I can't even install net - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoy8/AAoJEKXdFCfdEflK+a4P/056EtlWAr12QT7HdeoLhL2d +OQ2P53jd+fChB5NlrxKLot/+hvf+0PuJXkJU76hDBJ+1g9UkjSsYy1YGhPQ0rTU d5Ugqn0ZWIrON5QLx4CKH9XUjuN0jW2IlXXGpQApCrsBKv28vRM/oTi9jvC27IAP IdvD7QBUyN4L+K9z8cOWa1jckZahCrNrsWzgfoCDyJfDep+qeRXe0EbriHvXyfBm iT295qLUWjR1577bPRNwe7/H0tAe+yoexcJa/M3U4KiSX5qxlqwxr0aN6lFRNevj 1hB7xONTLa08sjx/NxzTID0zMoiZSlmkBLk/V3rj6uYkaFsjo89NvAfNhKZXerWf sLG/ivFKLFdeghZe6ItTDxIToTm0EnMPI8by8ZRD/xZ6MMre1QnDhODrVx0uMPl2 DRcoe3wItI1ZlX33I+ktF7iP5QZUvL59k15jBCoSnmU8mxSyM+REB/5O7IgLJvGI +SMoQB14+WwE/jDvz3HVqCifkwU2GDg3t3NT7lUq8yinovGjISufSuDdPY/croFl kgCLJ5JlEkHkv3EQPyce0ad6zkf6gpc4rWKv3hxxpSNDkKQ7CJyd51zF9S0bWztx 4KjAB5GJRNVxCEcWuh6F8/cSlh3yGTxrbJRh8M3SL1l3JPAo+xcK5nFwZ9Wz/ubk 3jpHrLIuH6+71NPsbZc/ =8QVC -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
Rich Freeman wrote: Now that Gentoo apparently offers a wide selection of network managers, perhaps it makes sense to have the user pick which one they want to use. +1 Rick Zero_Chaos Farina wrote: Choice is fine, I love choice, but to have a user unpack a stage tarball and find no way at all to handle their networking that's just ugly. The system where you unpack the stage likely already handles networking. I would say it is rare enough to not need net that removing all networking options from stage3 is near suicidal. I disagree. Not everything is connected. I also like that there's no syslog and no cron in stage3. I can do all kinds of amazing things on a system without an MTA. But if I have no net I can't even install net If you need net then make sure to install the manager you prefer during installation. I think that makes a lot of sense. //Peter
Re: [gentoo-dev] =net-fs/samba-4* vs. dev-libs/openssl[kerberos]
Lars Wendler schreef op vr 06-12-2013 om 16:24 [+0100]: Hi list, in [1] we got a bug where was pointed out that it is impossible to use =net-fs/samba-4* on a system which has dev-libs/openssl[kerberos] installed. Long story short, samba-4 hard requires app-crypt/heimdal while openssl[kerberos] hard requires app-crypt/mit-krb5. Of course both packages are mutually exclusive as both are their own kerberos implementation. The bug reporter suggests to use bundled heimdal from samba-4 which I would like to avoid if possible. If anyone knows some better solution please speak up. It is highly appreciated. [1] https://bugs.gentoo.org/490872 Kind regards Hi Lars, how about enabling the existing mit-krb5 support in Samba? Patch attached to the bug report. regards, Jorg
Re: [gentoo-dev] python versioned libraries or not
On Thu, 05 Dec 2013 13:32:09 +0900
hero...@gentoo.org wrote:
Dear all,
I have only one python-2.7 on my system. Simple and stupid.
After boost ebuild is converted to python-r1, libboost_python.so is
renamed to libboost_python-2.7.so. This is all cool about python-r1
for multiple python implementation support.
At the same time, I don't need this feature. I have a couple of
Jamroot's which append -lboost_python to LDFLAGS, and I have to
manually specify -lboost_python-2.7. Moreover, libraries depending
on boost.python, e.g. Boost.NumPy[1], searches for boost_python and
boost_python-mt only. I am forced to patch the build system to pass
-${PYVAR} to it, which is tedious.
Shouldn't pkg-conifg --libs handle this?
I am looking for a way out. Candidates are,
1. scan all python versioned libraries and symlink them to
unversioned one. Question: hints to do it systematically in
portage? Is there a helper available like python-exec?
2. python-single-r1 is ready for use, but it requires manipulating
the boost ebuild to change from python-r1, if I want a
python-single-r1 blessed boost. Question: How about merging
python-single-r1 with python-r1 and controlling by a global USE
flag python-single. When python-single is set, all ebuilds
inheriting python-r1 behaves as if being with python-single-r1,
so that all python versionings on executables and libraries are
disabled.
3. or something I missed
Comments?
Benda
1. https://github.com/ndarray/Boost.NumPy
---
Jan Matějka| Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B
signature.asc
Description: PGP signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, Dec 7, 2013 at 9:22 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: Choice is fine, I love choice, but to have a user unpack a stage tarball and find no way at all to handle their networking that's just ugly. I mean we could just have dhcpcd in @system and let people figure it out from there (wouldn't be my first choice but it would work) but I would say it is rare enough to not need net that removing all networking options from stage3 is near suicidal. I can do all kinds of amazing things on a system without an MTA. But if I have no net I can't even install net If you have no bootloader you can't install a bootloader. If you have no kernel... You don't need dhcpcd in your stage3 to chroot into your stage3 - the network is established by the install CD. You just lose the network if you reboot before you've installed a network manager, in which case you need to reboot from the CD, chroot, install the network manager, and then reboot again. It is no different than forgetting to install other popular and critical packages like lilo or pf-sources, and I don't see anybody suggesting that those should be on the stage3. I don't use WiFi so it isn't that big a deal for me personally, but I can see the argument in making the installation of a network manager part of the handbook. We already have a whole page on how to set up the network for the install CD itself assuming dhcp doesn't just work. Rich
Re: [gentoo-dev] python versioned libraries or not
yac y...@gentoo.org writes: Shouldn't pkg-conifg --libs handle this? Oh, good idea. But boost doesn't have pkg-config entries. Then I see this one, an upstream issue https://svn.boost.org/trac/boost/ticket/1094 Thanks. pgpf7FoU2HZeq.pgp Description: PGP signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
Rich Freeman wrote: I can see the argument in making the installation of a network manager part of the handbook. We already have a whole page on how to set up the network for the install CD itself assuming dhcp doesn't just work. I think the handbook should at a minimum have a recipe for replicating the same network manager setup as is on the CD. //Peter
