Re: [gentoo-dev] Re: Reverted python3.4 defaults
Le 19/07/2015 18:42, Ben de Groot a écrit : I would like to note that we only have around 50 packages that require python3, while the majority requires python2, and the remainder will function with either. How far are we from building a python3-only stage3? Are there any major blockers? Would any outside help be of use? Rémi
Re: [gentoo-dev] [RFC] Rebooting the Installer Project
On 18/07/15 21:01, Matthew Marchese wrote: I'd like to hear it all so please speak your mind. Looking forward to hearing from you. The plan is good, having multiple backends is a boon since then you can have large install images and tiny install images. An installer is basically covering partitioning, networking, audio/video configuration. If you can start with the simplest use-case and increase complexity gradually you will succeed. It is an exercise of patience and I praise you for giving it a try.
Re: [gentoo-dev] Re: Reverted python3.4 defaults
On Mon, Jul 20, 2015 at 10:39:25AM +0200, Dirkjan Ochtman wrote: On Mon, Jul 20, 2015 at 6:03 AM, Ben de Groot yng...@gentoo.org wrote: I don't see any strong technical reason to switch from python2 + python3 to python2-only enabled. Some people don't like having two versions of python installed -- that's about the gist of it. Indeed, there is no strong technical reason, except that some people like to keep their systems more lean. But I think having a smaller stage3 tarball is a more important reason. The python team has historically left that up to the RelEng team, which has been averse to handling that themselves. So, I'm personally not going to make that change without some kind of vote on it. I can arrange a vote within the python team if you like. I would like to hear from the other team members, yes. I have sympathy towards those who are asking for only one Python in stages (as in, I would be fine with that), but I very much think we should not leave Python 3 out of generally installed systems by default. We need to move through the transition, and increasing the barriers to Python 3 adoption will only make that process slower. I also feel like a voting process for this is probably not a solution. I also very much dislike shipping only python2. Having only one python is admirable and I'm all for it but if we only ship one by default it should be python3. Fedora's next release is going to ship only python3 in all their media (livecd, default install etc). Of course they will allow python2 to be installed too but that will have to be a concious choice by the user. https://fedoraproject.org/wiki/Changes/Python_3_as_Default I think the change next weekend should be as originally stated and have 2_7,3_4. Later on (perhaps we can see how fedora manages) we can see if dropping 2_7 from the default stages would be doable. -- Jason
Re: [gentoo-dev] Re: Reverted python3.4 defaults
On Mon, Jul 20, 2015 at 6:03 AM, Ben de Groot yng...@gentoo.org wrote: I don't see any strong technical reason to switch from python2 + python3 to python2-only enabled. Some people don't like having two versions of python installed -- that's about the gist of it. Indeed, there is no strong technical reason, except that some people like to keep their systems more lean. But I think having a smaller stage3 tarball is a more important reason. The python team has historically left that up to the RelEng team, which has been averse to handling that themselves. So, I'm personally not going to make that change without some kind of vote on it. I can arrange a vote within the python team if you like. I would like to hear from the other team members, yes. I have sympathy towards those who are asking for only one Python in stages (as in, I would be fine with that), but I very much think we should not leave Python 3 out of generally installed systems by default. We need to move through the transition, and increasing the barriers to Python 3 adoption will only make that process slower. I also feel like a voting process for this is probably not a solution. Cheers, Dirkjan
Re: [gentoo-dev] [RFC] Rebooting the Installer Project
Dnia 2015-07-18, o godz. 12:01:48 Matthew Marchese maffblas...@gentoo.org napisał(a): I have recently pressed the reboot button on the ol' Installer project. I've been able to talk to quite a few developers one-on-one via IRC concerning my plans. Most seem to be in support of Gentoo having a official installer (the biggest concern is appears to be how things will be implemented and the amount of features involved). This e-mail is to fulfill GLEP 39's request for comments (RFC), concerns, requests, etc. Since I'm a little new to the project I'm coming with a bit of ignorance; I know the previous Installer project fostered mixed feelings. If you'd like to review before replying you can see the Wiki page and find the source on GitHub: https://github.com/gentoo/stager To summarize I'm writing it in pure Python 3. It first will be able to create full backups (stage 4s) and recoveries. After that is finished I plan to move on to installations. There will potentially be a web interface UI for it. Others are free to create other front-ends; to me a web UI makes the most sense and would probably require the least deps. I'd like to hear it all so please speak your mind. Looking forward to hearing from you. On a semi-related note, I was thinking about doing a semi-related project :). I personally don't think Gentoo needs installer as-is. However, I think we'd really benefit from having some kind of helper scripts / checklist of tasks to be done prior to/after install. For example, you'd run 'check-my-install' script and it'd tell you what you likely forgot to set up :). -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgp4G9QzKPBlE.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Rebooting the Installer Project
On Mon, Jul 20, 2015 at 4:51 AM, Michał Górny mgo...@gentoo.org wrote: I personally don't think Gentoo needs installer as-is. However, I think we'd really benefit from having some kind of helper scripts / checklist of tasks to be done prior to/after install. I think something that would be really useful is better integration with configuration management tools (ansible, puppet, chef, etc). There are a few tools floating around but for the most part you're on your own with any of these. I'd really like to get to the point where I can be certain of being able to completely reproduce all my Gentoo boxes from configuration management tools - to the extent that other than cpu cycles it is as easy to just create a new vm/container/etc as it is to run emerge -u world on an existing one. For example, you'd run 'check-my-install' script and it'd tell you what you likely forgot to set up :). ++ - as long as it can be adapted to various uses. I don't need a bootloader and kernel on my container. As many times as I've installed Gentoo, I often manage to forget a step. -- Rich
Re: [gentoo-dev] [RFC] Rebooting the Installer Project
On Mon, 20 Jul 2015 10:51:00 +0200 Michał Górny wrote:
Dnia 2015-07-18, o godz. 12:01:48
Matthew Marchese maffblas...@gentoo.org napisał(a):
I have recently pressed the reboot button on the ol' Installer project.
I've been able to talk to quite a few developers one-on-one via IRC
concerning my plans. Most seem to be in support of Gentoo having a
official installer (the biggest concern is appears to be how things will
be implemented and the amount of features involved). This e-mail is to
fulfill GLEP 39's request for comments (RFC), concerns, requests, etc.
Since I'm a little new to the project I'm coming with a bit of ignorance; I
know the previous Installer project fostered mixed feelings.
If you'd like to review before replying you can see the Wiki page and find
the source on GitHub: https://github.com/gentoo/stager
To summarize I'm writing it in pure Python 3. It first will be able to
create full backups (stage 4s) and recoveries. After that is finished I
plan to move on to installations. There will potentially be a web interface
UI for it. Others are free to create other front-ends; to me a web UI makes
the most sense and would probably require the least deps.
I'd like to hear it all so please speak your mind. Looking forward to
hearing from you.
On a semi-related note, I was thinking about doing a semi-related
project :).
I personally don't think Gentoo needs installer as-is. However, I think
we'd really benefit from having some kind of helper scripts / checklist
of tasks to be done prior to/after install.
For example, you'd run 'check-my-install' script and it'd tell you what
you likely forgot to set up :).
Maybe a bit off-topic, but occasionally I need a tool to fast
install Gentoo and fine-tune it later. This happens quite often on
a new job box, oh during visits where I'm given a workstation and
3-4 hours to set it up before doing real work and so on.
The idea is to have binary-based Gentoo ready to work on general
common hardware with such software out of the box as fully-fledged
modern gui browsers (chromium, firefox), libreoffice, xterm,
screen, vim, compilers, ldap support and other dev tools. Set of
packages may vary, but the idea is that they should work out of the
box due to tight constrains on initial system configuration (boss
should see that I'm doing my job at the end of the day).
But afterwards I'd like to tune this setup in a usual Gentoo way:
configure kernel, USE flags, {C,CXX,F,FC,LD}FLAGS, select proper
alternatives and so on more or less accordant to the devmanual.
Self prepared catalyst build for general ~amd64 looks appropriate
to the task, but they require too much maintenance effort: each
update is a pain and quite time consuming and I need such images
only once or twice per year, but still I need them!
In the ideal world it would be nice to have such stage4 ebuilds
available to speed-up initial installation and configuration
process.
Best regards,
Andrew Savchenko
pgpNN4IylEdq1.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] Rebooting the Installer Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20.07.2015 10:51, Michał Górny wrote: [..] I think we'd really benefit from having some kind of helper scripts / checklist of tasks to be done prior to/after install. For example, you'd run 'check-my-install' script and it'd tell you what you likely forgot to set up :). +1 Sebastian
