* Roadmap for Guix 1.0 @ 2018-07-29 15:18 Ludovic Courtès 2018-07-30 1:23 ` Pjotr Prins ` (3 more replies) 0 siblings, 4 replies; 44+ messages in thread From: Ludovic Courtès @ 2018-07-29 15:18 UTC (permalink / raw) To: guix-devel [-- Attachment #1.1: Type: text/plain, Size: 886 bytes --] Hello Guix! I’ve pushed to guix/maintenance.git a list of things that IMO we should do or might want to do for 1.0, with the understanding that 1.0 should happen in 2018 (or early 2019 at the latest!). :-) https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org The list focuses on “big item” features and tasks, omitting routine bug fixes and improvements. Some of these items don’t require a lot of work or expertise though, so hopefully there’s enough on everyone’s plate. Feel free to comment, volunteer, add items (but not too many!), remove items, promote items, etc. Committers should feel free to edit the file directly in maintenance.git, especially to mark things as done. ;-) Copy of the file attached below. Ludo’. PS: I’m starting the discussion but will go AFK soon after sending this message. :-) [-- Attachment #1.2: The road to 1.0. --] [-- Type: text/x-org, Size: 2236 bytes --] #+TITLE: Roadmap for Guix 1.0, 2018 #+STARTUP: hidestars * 'guix pull' & co. ** TODO 'guix pull' honors ~/.config/guix/channels.scm *** (guix channels) module provides easy way to build a set of channels *** (guix inferior) uses that to allow interaction with an arbitrary Guix ** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883> ** TODO 'guix package -m' (?) allows users to specify a Guix channel ** TODO Profile manifest entries record the channel instance they come from ** TODO build-self.scm trampoline runs faster * UI/UX ** TODO Add colors for messages (error, warnings, hints, and possibly build logs) ** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass ** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310> ** MAYBE Add ‘guix install’ alias ** TODO Add ‘guix system --delete-generations’ ** MAYBE Polish & merge ‘wip-installer’ * core ** TODO Update & merge ‘wip-build-systems-gexp’ ** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms ** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co. ** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’) ** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap * infrastructure ** TODO ci.guix.gnu.org points to berlin.guixsd.org ** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated ** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org ** TODO Tatiana's web UI deployed on berlin.guixsd.org ** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.) ** TODO web site available at guix.gnu.org *** DNS already set up with two entries, but how to do deal with LE certs and all? ** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org ** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days ** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?) * miscellaneous ** TODO “GuixSD” renamed to “Guix System”? ** TODO “Cuirass” renamed to “Guix CI”? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès @ 2018-07-30 1:23 ` Pjotr Prins 2018-07-30 9:02 ` Nils Gillmann 2018-08-29 16:12 ` Roadmap for Guix 1.0 Amirouche Boubekki 2018-07-30 5:08 ` Chris Marusich ` (2 subsequent siblings) 3 siblings, 2 replies; 44+ messages in thread From: Pjotr Prins @ 2018-07-30 1:23 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote: > #+TITLE: Roadmap for Guix 1.0, 2018 > #+STARTUP: hidestars > > * 'guix pull' & co. > ** TODO 'guix pull' honors ~/.config/guix/channels.scm > *** (guix channels) module provides easy way to build a set of channels > *** (guix inferior) uses that to allow interaction with an arbitrary Guix > ** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883> > ** TODO 'guix package -m' (?) allows users to specify a Guix channel > ** TODO Profile manifest entries record the channel instance they come from > ** TODO build-self.scm trampoline runs faster > * UI/UX > ** TODO Add colors for messages (error, warnings, hints, and possibly build logs) > ** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass > ** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310> > ** MAYBE Add ‘guix install’ alias > ** TODO Add ‘guix system --delete-generations’ > ** MAYBE Polish & merge ‘wip-installer’ > * core > ** TODO Update & merge ‘wip-build-systems-gexp’ > ** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms > ** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co. > ** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’) > ** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap > * infrastructure > ** TODO ci.guix.gnu.org points to berlin.guixsd.org > ** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated > ** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org > ** TODO Tatiana's web UI deployed on berlin.guixsd.org > ** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.) > ** TODO web site available at guix.gnu.org > *** DNS already set up with two entries, but how to do deal with LE certs and all? > ** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org > ** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days > ** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?) > * miscellaneous > ** TODO “GuixSD” renamed to “Guix System”? > ** TODO “Cuirass” renamed to “Guix CI”? Are these all really necessary for 1.0? Or can it be 1.1? I think we are pushing ourselves too much to have all deployment tools and website stuff aligned ;) Q: how large a big storage do we need for TTL>60d today? I don't have a build farm in the USA, but I can create a mirror if you allow rsync and have guix publish running on guix.genenetwork.org (or any name, really). Is that of interest? Pj. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-30 1:23 ` Pjotr Prins @ 2018-07-30 9:02 ` Nils Gillmann 2018-07-30 12:47 ` Pierre Neidhardt 2018-08-29 16:12 ` Roadmap for Guix 1.0 Amirouche Boubekki 1 sibling, 1 reply; 44+ messages in thread From: Nils Gillmann @ 2018-07-30 9:02 UTC (permalink / raw) To: Pjotr Prins; +Cc: guix-devel Pjotr Prins transcribed 2.9K bytes: > On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote: > > #+TITLE: Roadmap for Guix 1.0, 2018 > > #+STARTUP: hidestars > > > > * 'guix pull' & co. > > ** TODO 'guix pull' honors ~/.config/guix/channels.scm > > *** (guix channels) module provides easy way to build a set of channels > > *** (guix inferior) uses that to allow interaction with an arbitrary Guix > > ** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883> > > ** TODO 'guix package -m' (?) allows users to specify a Guix channel > > ** TODO Profile manifest entries record the channel instance they come from > > ** TODO build-self.scm trampoline runs faster > > * UI/UX > > ** TODO Add colors for messages (error, warnings, hints, and possibly build logs) > > ** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass > > ** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310> > > ** MAYBE Add ‘guix install’ alias > > ** TODO Add ‘guix system --delete-generations’ > > ** MAYBE Polish & merge ‘wip-installer’ > > * core > > ** TODO Update & merge ‘wip-build-systems-gexp’ > > ** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms > > ** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co. > > ** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’) > > ** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap > > * infrastructure > > ** TODO ci.guix.gnu.org points to berlin.guixsd.org > > ** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated > > ** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org > > ** TODO Tatiana's web UI deployed on berlin.guixsd.org > > ** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.) > > ** TODO web site available at guix.gnu.org > > *** DNS already set up with two entries, but how to do deal with LE certs and all? > > ** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org > > ** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days > > ** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?) > > * miscellaneous > > ** TODO “GuixSD” renamed to “Guix System”? > > ** TODO “Cuirass” renamed to “Guix CI”? > > Are these all really necessary for 1.0? Or can it be 1.1? I think we > are pushing ourselves too much to have all deployment tools and > website stuff aligned ;) I think it's okay. In the end version numbers are just numbers. We are at 0.15, so we can go all the way up to 1.0 with many version releases between to fit in parts of 1.0. > Q: how large a big storage do we need for TTL>60d today? I don't have > a build farm in the USA, but I can create a mirror if you allow rsync > and have guix publish running on guix.genenetwork.org (or any name, > really). Is that of interest? > > Pj. > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-30 9:02 ` Nils Gillmann @ 2018-07-30 12:47 ` Pierre Neidhardt 2018-08-19 11:06 ` LVM support Ludovic Courtès 0 siblings, 1 reply; 44+ messages in thread From: Pierre Neidhardt @ 2018-07-30 12:47 UTC (permalink / raw) To: Nils Gillmann; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 67 bytes --] Also how far did we go with LVM support? -- Pierre Neidhardt [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* LVM support 2018-07-30 12:47 ` Pierre Neidhardt @ 2018-08-19 11:06 ` Ludovic Courtès 0 siblings, 0 replies; 44+ messages in thread From: Ludovic Courtès @ 2018-08-19 11:06 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel, Nils Gillmann Hi! Pierre Neidhardt <ambrevar@gmail.com> skribis: > Also how far did we go with LVM support? This was discussed looong ago (whether/how the device-mapping code would be a good fit for LVM) but we don’t have any code. This would be nice to have, though I wouldn’t consider it a blocker for 1.0. Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-30 1:23 ` Pjotr Prins 2018-07-30 9:02 ` Nils Gillmann @ 2018-08-29 16:12 ` Amirouche Boubekki 2018-08-30 11:46 ` Pierre Neidhardt 1 sibling, 1 reply; 44+ messages in thread From: Amirouche Boubekki @ 2018-08-29 16:12 UTC (permalink / raw) To: Pjotr Prins; +Cc: guix-devel, Guix-devel "There are only two hard problems in Computer Science: cache invalidation and naming things" On 2018-07-30 03:23, Pjotr Prins wrote: > On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote: >> #+TITLE: Roadmap for Guix 1.0, 2018 >> * miscellaneous >> ** TODO “GuixSD” renamed to “Guix System”? Guix System is not good because "system" is a word that is too generic. What about "Guix OS"? >> ** TODO “Cuirass” renamed to “Guix CI”? OK ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-29 16:12 ` Roadmap for Guix 1.0 Amirouche Boubekki @ 2018-08-30 11:46 ` Pierre Neidhardt 2018-08-30 12:04 ` Ludovic Courtès 2018-08-30 21:45 ` Taylan Kammer 0 siblings, 2 replies; 44+ messages in thread From: Pierre Neidhardt @ 2018-08-30 11:46 UTC (permalink / raw) To: Amirouche Boubekki; +Cc: guix-devel, Guix-devel [-- Attachment #1: Type: text/plain, Size: 1228 bytes --] > >> ** TODO “GuixSD” renamed to “Guix System”? > > Guix System is not good because "system" is a word that is too generic. > > What about "Guix OS"? > > >> ** TODO “Cuirass” renamed to “Guix CI”? > > OK On the one hand, OS and CI are rather ubiquitous. On the other hand, I've personally always been wary of excessive use of abbreviations: newcomers will find documentation and communication cryptic, while abbreviations proliferate, sometimes out of control. But I don't think it's the case for Guix OS and even Apple went for "macOS" so I guess "OS" is pretty safe (much more than "SD" at least). Conversely, "Guix CI" is much less widespread, although I suppose many developers are familiar with the term. I personally prefer unique, easy names to abbreviations. - The name "Guix CI" tells developers what it is (continuous integration) while "Cuirass" does not. This is mostly true, however, for almost all applications (mpv, firefox, chromium, emacs, <add almost everything here>). - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we will end up with a bunch Guix FS, Guix IP, Guix CD... -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 11:46 ` Pierre Neidhardt @ 2018-08-30 12:04 ` Ludovic Courtès 2018-08-30 12:57 ` Ricardo Wurmus ` (3 more replies) 2018-08-30 21:45 ` Taylan Kammer 1 sibling, 4 replies; 44+ messages in thread From: Ludovic Courtès @ 2018-08-30 12:04 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel, Guix-devel Hello, Pierre Neidhardt <mail@ambrevar.xyz> skribis: > Conversely, "Guix CI" is much less widespread, although I suppose many > developers are familiar with the term. I personally prefer unique, easy names > to abbreviations. > > - The name "Guix CI" tells developers what it is (continuous integration) while > "Cuirass" does not. This is mostly true, however, for almost all applications > (mpv, firefox, chromium, emacs, <add almost everything here>). > > - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we > will end up with a bunch Guix FS, Guix IP, Guix CD... I think “Guix System” is OK. Most of the time we’ll just say “Guix”, as is already the case, and when we need to disambiguate (for instance when addressing bugs), we’ll ask “Are you using Guix System?” or “Are you using the Guix distro?”, and everything will be fine. :-) The motivation for this name change is that “SD” is obscure to most, as you note, plus it creates confusion when people visit the web site: the web site has a “GuixSD” logo, but then it talks about features of the package manager. Designating the whole tool set as “Guix” will simplify this, and we can always be more specific when we need to. For Cuirass, I think “Guix CI” (or “Guix Continuous”?) is good enough. It remains a tool primarily for Guix developers anyway, and a secondary tool in the Guix toolbox. Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 12:04 ` Ludovic Courtès @ 2018-08-30 12:57 ` Ricardo Wurmus 2018-08-30 14:20 ` Tobias Geerinckx-Rice 2018-08-30 19:13 ` George Clemmer 2018-08-30 15:36 ` George Clemmer ` (2 subsequent siblings) 3 siblings, 2 replies; 44+ messages in thread From: Ricardo Wurmus @ 2018-08-30 12:57 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, Guix-devel Ludovic Courtès <ludo@gnu.org> writes: > Hello, > > Pierre Neidhardt <mail@ambrevar.xyz> skribis: > >> Conversely, "Guix CI" is much less widespread, although I suppose many >> developers are familiar with the term. I personally prefer unique, easy names >> to abbreviations. >> >> - The name "Guix CI" tells developers what it is (continuous integration) while >> "Cuirass" does not. This is mostly true, however, for almost all applications >> (mpv, firefox, chromium, emacs, <add almost everything here>). >> >> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we >> will end up with a bunch Guix FS, Guix IP, Guix CD... > > I think “Guix System” is OK. I think so too. > Most of the time we’ll just say “Guix”, as > is already the case, and when we need to disambiguate (for instance when > addressing bugs), we’ll ask “Are you using Guix System?” or “Are you > using the Guix distro?”, and everything will be fine. :-) Exactly. I wrote this on IRC: The name “GuixSD” is opaque and creates an arbitrary distinction between the system running on bare metal and the systems you can create with the “guix system” commands. It makes it difficult to communicate about Guix. Do we really offer “a package manager” and a “distro” — or is it really all one thing with various levels? The “guix system” command can be used without GuixSD to create Guix virtual machines or containers. Describing “guix system” is difficult when we think in terms of “package manager” vs “distro”. Guix itself is also a distro – none of the packages it provides link with the host system, and the collection of packages is a distribution of free software. I think that simplifying the name by using “guix” as a category will make communication easier. > The motivation for this name change is that “SD” is obscure to most, as > you note, plus it creates confusion when people visit the web site: the > web site has a “GuixSD” logo, but then it talks about features of the > package manager. Designating the whole tool set as “Guix” will simplify > this, and we can always be more specific when we need to. I agree. -- Ricardo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 12:57 ` Ricardo Wurmus @ 2018-08-30 14:20 ` Tobias Geerinckx-Rice 2018-08-30 15:17 ` Nils Gillmann 2018-08-30 19:13 ` George Clemmer 1 sibling, 1 reply; 44+ messages in thread From: Tobias Geerinckx-Rice @ 2018-08-30 14:20 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel, Guix-devel Guix, Ricardo Wurmus wrote: > Ludovic Courtès <ludo@gnu.org> writes: >> I think “Guix System” is OK. > > I think so too. Big +1. If you use 'guix system', you're using Guix System[0]. It doesn't get less confusing than that. Kind regards, T G-R [0]: The only question left is 'on what?'. Everything, of course. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 14:20 ` Tobias Geerinckx-Rice @ 2018-08-30 15:17 ` Nils Gillmann 0 siblings, 0 replies; 44+ messages in thread From: Nils Gillmann @ 2018-08-30 15:17 UTC (permalink / raw) To: Tobias Geerinckx-Rice; +Cc: guix-devel, Guix-devel Tobias Geerinckx-Rice transcribed 340 bytes: > Guix, > > Ricardo Wurmus wrote: > > Ludovic Courtès <ludo@gnu.org> writes: > > > I think “Guix System” is OK. > > > > I think so too. > > Big +1. > > If you use 'guix system', you're using Guix System[0]. > > It doesn't get less confusing than that. > > Kind regards, > > T G-R > > [0]: The only question left is 'on what?'. Everything, of course. > Sounds good for me too. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 12:57 ` Ricardo Wurmus 2018-08-30 14:20 ` Tobias Geerinckx-Rice @ 2018-08-30 19:13 ` George Clemmer 2018-08-30 20:12 ` Gábor Boskovits 1 sibling, 1 reply; 44+ messages in thread From: George Clemmer @ 2018-08-30 19:13 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel, Guix-devel Ricardo Wurmus <rekado@elephly.net> writes: > Ludovic Courtès <ludo@gnu.org> writes: > >> Hello, >> >> I think “Guix System” is OK. > > I think so too. I recommend against renaming GuixSD >> "Guix System". Here is Why: 1) A noob would expect "guix system" to refer to the whole Guix enchilada. If we use it to refer to GuixSD, a specific Guix deployment mode, we have created a new, counter-intuitive thing we have to explain. 2) As Ricardo points out below, the "guix system" command clashes with this use of Guix system. This is a second counter-intuitive thing we would have to explain. Bottom line: we shouln'd use the general term "Guix System" in any way beyond, perhaps in a descriptway way, e.g., The Guix project develops the Guix System, a set of tools that manage software environments. >> Most of the time we’ll just say “Guix”, as >> is already the case, and when we need to disambiguate (for instance when >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you >> using the Guix distro?”, and everything will be fine. :-) > > Exactly. > > I wrote this on IRC: > > The name “GuixSD” is opaque and creates an arbitrary distinction between > the system running on bare metal and the systems you can create with the > “guix system” commands. It makes it difficult to communicate about > Guix. Do we really offer “a package manager” and a “distro” — or is it > really all one thing with various levels? > > The “guix system” command can be used without GuixSD to create Guix > virtual machines or containers. Describing “guix system” is difficult > when we think in terms of “package manager” vs “distro”. Guix itself is > also a distro – none of the packages it provides link with the host > system, and the collection of packages is a distribution of free > software. > > I think that simplifying the name by using “guix” as a category will > make communication easier. > >> The motivation for this name change is that “SD” is obscure to most, as >> you note, plus it creates confusion when people visit the web site: the >> web site has a “GuixSD” logo, but then it talks about features of the >> package manager. Designating the whole tool set as “Guix” will simplify >> this, and we can always be more specific when we need to. > > I agree. I agree too. You may recall that I recommendi this approach when we discussed the web site in January. That thread includes a product description [1] that might be a good place to start when describing the "whole tool set". [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 19:13 ` George Clemmer @ 2018-08-30 20:12 ` Gábor Boskovits 2018-08-31 14:25 ` George Clemmer 0 siblings, 1 reply; 44+ messages in thread From: Gábor Boskovits @ 2018-08-30 20:12 UTC (permalink / raw) To: myglc2; +Cc: Guix-devel, guix-devel-bounces+amirouche=hypermove.net [-- Attachment #1: Type: text/plain, Size: 3128 bytes --] George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. aug. 30., Cs, 21:14): > > Ricardo Wurmus <rekado@elephly.net> writes: > > > Ludovic Courtès <ludo@gnu.org> writes: > > > >> Hello, > >> > >> I think “Guix System” is OK. > > > > I think so too. > > I recommend against renaming GuixSD >> "Guix System". Here is Why: > > 1) A noob would expect "guix system" to refer to the whole Guix > enchilada. If we use it to refer to GuixSD, a specific Guix deployment > mode, we have created a new, counter-intuitive thing we have to explain. > > 2) As Ricardo points out below, the "guix system" command clashes with > this use of Guix system. This is a second counter-intuitive thing we > would have to explain. > > Bottom line: we shouln'd use the general term "Guix System" in any way > beyond, perhaps in a descriptway way, e.g., The Guix project develops > the Guix System, a set of tools that manage software environments. > > >> Most of the time we’ll just say “Guix”, as > >> is already the case, and when we need to disambiguate (for instance when > >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you > >> using the Guix distro?”, and everything will be fine. :-) > > > > Exactly. > > > > I wrote this on IRC: > > > > The name “GuixSD” is opaque and creates an arbitrary distinction between > > the system running on bare metal and the systems you can create with the > > “guix system” commands. It makes it difficult to communicate about > > Guix. Do we really offer “a package manager” and a “distro” — or is it > > really all one thing with various levels? > > > > The “guix system” command can be used without GuixSD to create Guix > > virtual machines or containers. Describing “guix system” is difficult > > when we think in terms of “package manager” vs “distro”. Guix itself is > > also a distro – none of the packages it provides link with the host > > system, and the collection of packages is a distribution of free > > software. > > > > I think that simplifying the name by using “guix” as a category will > > make communication easier. > > > >> The motivation for this name change is that “SD” is obscure to most, as > >> you note, plus it creates confusion when people visit the web site: the > >> web site has a “GuixSD” logo, but then it talks about features of the > >> package manager. Designating the whole tool set as “Guix” will simplify > >> this, and we can always be more specific when we need to. > > > > I agree. > > I agree too. You may recall that I recommendi this approach when we > discussed the web site in January. That thread includes a product > description [1] that might be a good place to start when describing the > "whole tool set". > > [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html > > What do you think about GuixSD >> "Guix Distribution"? This naming seems to resolve the ambiguities mentioned so far, and has a widespread use, that exactly matches the intended meaning. WDYT? [-- Attachment #2: Type: text/html, Size: 3993 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 20:12 ` Gábor Boskovits @ 2018-08-31 14:25 ` George Clemmer 2018-08-31 15:45 ` Vincent Legoll 0 siblings, 1 reply; 44+ messages in thread From: George Clemmer @ 2018-08-31 14:25 UTC (permalink / raw) To: Gábor Boskovits Cc: Guix-devel, guix-devel-bounces+amirouche=hypermove.net Gábor Boskovits <boskovits@gmail.com> writes: > George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. aug. 30., Cs, > 21:14): > >> >> Ricardo Wurmus <rekado@elephly.net> writes: >> >> > Ludovic Courtès <ludo@gnu.org> writes: >> > >> >> Hello, >> >> >> >> I think “Guix System” is OK. >> > >> > I think so too. >> >> I recommend against renaming GuixSD >> "Guix System". Here is Why: >> >> 1) A noob would expect "guix system" to refer to the whole Guix >> enchilada. If we use it to refer to GuixSD, a specific Guix deployment >> mode, we have created a new, counter-intuitive thing we have to explain. >> >> 2) As Ricardo points out below, the "guix system" command clashes with >> this use of Guix system. This is a second counter-intuitive thing we >> would have to explain. >> >> Bottom line: we shouln'd use the general term "Guix System" in any way >> beyond, perhaps in a descriptway way, e.g., The Guix project develops >> the Guix System, a set of tools that manage software environments. >> >> >> Most of the time we’ll just say “Guix”, as >> >> is already the case, and when we need to disambiguate (for instance when >> >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you >> >> using the Guix distro?”, and everything will be fine. :-) >> > >> > Exactly. >> > >> > I wrote this on IRC: >> > >> > The name “GuixSD” is opaque and creates an arbitrary distinction between >> > the system running on bare metal and the systems you can create with the >> > “guix system” commands. It makes it difficult to communicate about >> > Guix. Do we really offer “a package manager” and a “distro” — or is it >> > really all one thing with various levels? >> > >> > The “guix system” command can be used without GuixSD to create Guix >> > virtual machines or containers. Describing “guix system” is difficult >> > when we think in terms of “package manager” vs “distro”. Guix itself is >> > also a distro – none of the packages it provides link with the host >> > system, and the collection of packages is a distribution of free >> > software. >> > >> > I think that simplifying the name by using “guix” as a category will >> > make communication easier. >> > >> >> The motivation for this name change is that “SD” is obscure to most, as >> >> you note, plus it creates confusion when people visit the web site: the >> >> web site has a “GuixSD” logo, but then it talks about features of the >> >> package manager. Designating the whole tool set as “Guix” will simplify >> >> this, and we can always be more specific when we need to. >> > >> > I agree. >> >> I agree too. You may recall that I recommendi this approach when we >> discussed the web site in January. That thread includes a product >> description [1] that might be a good place to start when describing the >> "whole tool set". >> >> [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html >> >> What do you think about GuixSD >> "Guix Distribution"? This naming seems > to resolve the ambiguities mentioned so far, and has a widespread > use, that exactly matches the intended meaning. WDYT? Hi Gábor, I think this discussion was primarily triggered by the realization that we can improve the top-level presentation of Guix by downplaying the distinction between Guix and GuixSD. In fact, we could delay the introduction of Guix/GuixSD to the download page. A more informative download page might look like: Use Guix to manage ... entire computers: GuixSD download options: x86_64 i686 VMs: download options: GuixSD x86_64-QEMU-image GNU/Linux user environments: Guix download options: x86_64, i686, armhf, aarch64 Here we see the primary purpose of the Guix/GuixSD labels is to identify the different download options and to enable the user to find the correct install instructions and doc sections for whatever they download. GuixSD doesn't necessarily need to be changed. But the issue has been raised, as mentioned above, that because "SD" is not a recognized abbreviation "GuixSD" carries no intuitive meaning. If we want an improved label for the Guix system distribution, the best one is probably "GuixOS" since "OS" is a widely used and recognized abbreviation ... Term google hits OS 3.0 * 10**9 operating system 0.7 * 10**9 system distribution 0.5 * 10**9 I guess the issue with this is that it seems odd to say "the GNU Guix GNU/Linux System Distribution, abbreviated GuixOS" ;-) HTH - George ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-31 14:25 ` George Clemmer @ 2018-08-31 15:45 ` Vincent Legoll 2018-08-31 15:54 ` Amirouche Boubekki 0 siblings, 1 reply; 44+ messages in thread From: Vincent Legoll @ 2018-08-31 15:45 UTC (permalink / raw) To: myglc2; +Cc: guix-devel, guix-devel-bounces+amirouche=hypermove.net Hello, I was refraining to answer, but this: On Fri, Aug 31, 2018 at 4:29 PM George Clemmer <myglc2@gmail.com> wrote: > I think this discussion was primarily triggered by the realization that > we can improve the top-level presentation of Guix by downplaying the > distinction between Guix and GuixSD. In fact, we could delay the > introduction of Guix/GuixSD to the download page. > > A more informative download page might look like: > > Use Guix to manage ... > > entire computers: GuixSD download options: x86_64 i686 > > VMs: download options: GuixSD x86_64-QEMU-image > > GNU/Linux user environments: Guix download options: x86_64, i686, armhf, > aarch64 > > Here we see the primary purpose of the Guix/GuixSD labels is to identify > the different download options and to enable the user to find the > correct install instructions and doc sections for whatever they > download. > > GuixSD doesn't necessarily need to be changed. But the issue has been > raised, as mentioned above, that because "SD" is not a recognized > abbreviation "GuixSD" carries no intuitive meaning. If we want an > improved label for the Guix system distribution, the best one is > probably "GuixOS" since "OS" is a widely used and recognized > abbreviation ... Is exactly my opinion also, so it gets a +1 Bye -- Vincent Legoll ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-31 15:45 ` Vincent Legoll @ 2018-08-31 15:54 ` Amirouche Boubekki 2018-09-01 7:36 ` rchar01 0 siblings, 1 reply; 44+ messages in thread From: Amirouche Boubekki @ 2018-08-31 15:54 UTC (permalink / raw) To: vincent.legoll Cc: guix-devel, guix-devel-bounces+amirouche=hypermove.net, myglc2 > > >If we want an > > improved label for the Guix system distribution, the best one is > > probably "GuixOS" since "OS" is a widely used and recognized > > abbreviation ... > > Is exactly my opinion also, so it gets a +1 > Top 3: 1) GuixOS 2) Guix 3) Guix System ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-31 15:54 ` Amirouche Boubekki @ 2018-09-01 7:36 ` rchar01 2018-09-01 9:27 ` Pjotr Prins 0 siblings, 1 reply; 44+ messages in thread From: rchar01 @ 2018-09-01 7:36 UTC (permalink / raw) To: guix-devel@gnu.org; +Cc: myglc2@gmail.com As an example, PureOS had a similar idea for the name. - https://www.pureos.net/ - from https://www.gnu.org/distros/free-distros.en.html Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On August 31, 2018 5:54 PM, Amirouche Boubekki <amirouche.boubekki@gmail.com> wrote: > > > > If we want an > > > > improved label for the Guix system distribution, the best one is > > > > probably "GuixOS" since "OS" is a widely used and recognized > > > > abbreviation ... > > > > Is exactly my opinion also, so it gets a +1 > > Top 3: > > 1. GuixOS > 2. Guix > 3. Guix System ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-09-01 7:36 ` rchar01 @ 2018-09-01 9:27 ` Pjotr Prins 2018-09-01 10:09 ` Nils Gillmann 0 siblings, 1 reply; 44+ messages in thread From: Pjotr Prins @ 2018-09-01 9:27 UTC (permalink / raw) To: rchar01; +Cc: guix-devel@gnu.org, myglc2@gmail.com On Sat, Sep 01, 2018 at 07:36:35AM +0000, rchar01 wrote: > As an example, PureOS had a similar idea for the name. > > - https://www.pureos.net/ > - from https://www.gnu.org/distros/free-distros.en.html We should have some flavours: FunGuixOs SeriousGuixOs VerySeriousGuixOS VerySeriousGuixOSIndeed Just kidding. GuixOS sounds fine to me. How will be distinguish between Linux and Hurd? GuixLinuxOS GuixHurdOS or simplify to GNU Guix Linux GNU Guix Hurd Pj. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-09-01 9:27 ` Pjotr Prins @ 2018-09-01 10:09 ` Nils Gillmann 0 siblings, 0 replies; 44+ messages in thread From: Nils Gillmann @ 2018-09-01 10:09 UTC (permalink / raw) To: Pjotr Prins; +Cc: guix-devel@gnu.org, myglc2@gmail.com Pjotr Prins transcribed 466 bytes: > On Sat, Sep 01, 2018 at 07:36:35AM +0000, rchar01 wrote: > > As an example, PureOS had a similar idea for the name. > > > > - https://www.pureos.net/ > > - from https://www.gnu.org/distros/free-distros.en.html > > We should have some flavours: > > FunGuixOs > SeriousGuixOs > VerySeriousGuixOS > VerySeriousGuixOSIndeed > > Just kidding. GuixOS sounds fine to me. How will be distinguish > between Linux and Hurd? We don't have to. Why would you want this? Simply give a download a descriptive name, and put the details in parens behind it or a proper description box. Imagine we get support for one of the BSD kernels in the future. And then a variant which builds our own BSD-based GuixSD/OS.. you don't need to come up with a new name every time. GuixOS (Linux-libre) GuixOS (Hurd) GuixOS (obsd) easy as that > GuixLinuxOS > GuixHurdOS > > or simplify to > > GNU Guix Linux > GNU Guix Hurd > > Pj. > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 12:04 ` Ludovic Courtès 2018-08-30 12:57 ` Ricardo Wurmus @ 2018-08-30 15:36 ` George Clemmer 2018-08-30 17:11 ` Hartmut Goebel 2018-08-30 18:17 ` Jan Nieuwenhuizen 3 siblings, 0 replies; 44+ messages in thread From: George Clemmer @ 2018-08-30 15:36 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, Guix-devel Hi, Ludovic Courtès <ludo@gnu.org> writes: > Hello, > > Pierre Neidhardt <mail@ambrevar.xyz> skribis: > >> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we >> will end up with a bunch Guix FS, Guix IP, Guix CD... > > I think “Guix System” is OK. Most of the time we’ll just say “Guix”, as > is already the case, and when we need to disambiguate (for instance when > addressing bugs), we’ll ask “Are you using Guix System?” or “Are you > using the Guix distro?”, and everything will be fine. :-) > > The motivation for this name change is that “SD” is obscure to most, as > you note, plus it creates confusion when people visit the web site: the > web site has a “GuixSD” logo, but then it talks about features of the > package manager. Designating the whole tool set as “Guix” will simplify > this, and we can always be more specific when we need to. This is good because it declutters the Guix-Verse for new users. I suggest that the distinction between GuixOS, package manager, QEMU image, and source can be re-positioned as download options. We could simplify the choice of these by improving the download page. For example ... 1) We could simplify the download labels/descriptions, e.g., "GuixSD 0.15.0 QEMU Image QCOW2 virtual machine (VM) image. Download options: x86_64" ... might become ... "x86_64 VM (GuixSD 0.15.0 QEMU Image QCOW2 virtual machine image)" 2) We could add a feature check list that helps with download selection. With such changes the support question is: what did you download? IMO it would be desirable to pick a single term for each download option and use it obsessively throughout the site and doc. This small thing can be quite helpful to a noob because it eliminates any confusion that might be caused by multiple terms meaning the same thing. So, IMO we should settle on only one of Guix System, GuixSD, GuixOS, or maybe "Guix bare metal". - George ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 12:04 ` Ludovic Courtès 2018-08-30 12:57 ` Ricardo Wurmus 2018-08-30 15:36 ` George Clemmer @ 2018-08-30 17:11 ` Hartmut Goebel 2018-08-30 18:17 ` Jan Nieuwenhuizen 3 siblings, 0 replies; 44+ messages in thread From: Hartmut Goebel @ 2018-08-30 17:11 UTC (permalink / raw) To: guix-devel Am 30.08.2018 um 14:04 schrieb Ludovic Courtès: > “Guix Continuous” For me this sounds like a fail-save system which will continue running, and running, and running. -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 12:04 ` Ludovic Courtès ` (2 preceding siblings ...) 2018-08-30 17:11 ` Hartmut Goebel @ 2018-08-30 18:17 ` Jan Nieuwenhuizen 3 siblings, 0 replies; 44+ messages in thread From: Jan Nieuwenhuizen @ 2018-08-30 18:17 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, Guix-devel Ludovic Courtès writes: > I think “Guix System” is OK. Most of the time we’ll just say “Guix”, as > is already the case, and when we need to disambiguate (for instance when > addressing bugs), we’ll ask “Are you using Guix System?” or “Are you > using the Guix distro?”, and everything will be fine. :-) Yes, I found that "SD" is often more confusing than not. janneke -- Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-30 11:46 ` Pierre Neidhardt 2018-08-30 12:04 ` Ludovic Courtès @ 2018-08-30 21:45 ` Taylan Kammer 1 sibling, 0 replies; 44+ messages in thread From: Taylan Kammer @ 2018-08-30 21:45 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel, Guix-devel Pierre Neidhardt <mail@ambrevar.xyz> writes: > - The name "Guix CI" tells developers what it is (continuous integration) while > "Cuirass" does not. This is mostly true, however, for almost all applications > (mpv, firefox, chromium, emacs, <add almost everything here>). Just an anecdote: I didn't know what Cuirass was until I read this thread, though I saw the name many times. :-) Taylan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès 2018-07-30 1:23 ` Pjotr Prins @ 2018-07-30 5:08 ` Chris Marusich 2018-07-30 7:33 ` Pierre Neidhardt 2018-08-19 11:11 ` Ludovic Courtès 2018-08-19 21:52 ` Amirouche Boubekki 2018-09-04 22:55 ` fis trivial 3 siblings, 2 replies; 44+ messages in thread From: Chris Marusich @ 2018-07-30 5:08 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 797 bytes --] ludo@gnu.org (Ludovic Courtès) writes: > #+TITLE: Roadmap for Guix 1.0, 2018 A lot of good stuff! I hope I can find the time to help knock out some of these things. At the moment, I only have this to add: It would be nice if we could decide on how we will use version numbers going forward and publish a description of that in the manual or on the website. I think the important thing is that we publish a description. The details of it are less important. We can use Semantic Versioning [1], Sentimental Versioning [2], or something totally different. As long as we publish our decision and stick to it, everyone will know what to expect. Footnotes: [1] https://semver.org/ [2] It's not my top choice, though! http://sentimentalversioning.org/ -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-30 5:08 ` Chris Marusich @ 2018-07-30 7:33 ` Pierre Neidhardt 2018-08-19 11:19 ` Ludovic Courtès 2018-08-19 11:11 ` Ludovic Courtès 1 sibling, 1 reply; 44+ messages in thread From: Pierre Neidhardt @ 2018-07-30 7:33 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 1470 bytes --] > Sentimental Versioning Didn't know about this, interesting take... :) My two cents because I'm not sure it fits the list: - `man' is broken. https://lists.gnu.org/archive/html/help-guix/2018-05/msg00084.html It seems trivial but I don't think we should put a 1.0 stamp on an OS that can't display standard documentation correctly. I'll open a bug about it, I can work on it later. - As Julien mentioned recently, I think we should provide a "stable" channel. Is it already implied by the new (guix channel) module? - `guix package --upgrade' reverses the order of packages. https://lists.gnu.org/archive/html/help-guix/2018-04/msg00070.html https://bugs.gnu.org/31142 I think "infinite upgrades" will look very ugly to the casual user, we ought to fix that :) - TeXlive... (sigh!) TeXlive is rather important for lots of users but also lots of packages. Some packages (e.g. "asymptote" and "mit-scheme") currently depend on the full TeXlive distribution (5GB). This is way too much for many users (low disk space, low bandwidth, or simply lack of time). I'm working on adding the missing individual TeXlive packages, but it's surprisingly hard, so help is more than welcome. https://lists.gnu.org/archive/html/help-guix/2018-05/msg00218.html We also need a user hook to install individual packages to the user profile: https://bugs.gnu.org/27217 Anything among these deemed for a post 1.0 release? -- Pierre Neidhardt [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-30 7:33 ` Pierre Neidhardt @ 2018-08-19 11:19 ` Ludovic Courtès 0 siblings, 0 replies; 44+ messages in thread From: Ludovic Courtès @ 2018-08-19 11:19 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel Hello, Pierre Neidhardt <ambrevar@gmail.com> skribis: > My two cents because I'm not sure it fits the list: > > - `man' is broken. > https://lists.gnu.org/archive/html/help-guix/2018-05/msg00084.html [...] > - As Julien mentioned recently, I think we should provide a "stable" > channel. Is it already implied by the new (guix channel) module? > > - `guix package --upgrade' reverses the order of packages. > https://lists.gnu.org/archive/html/help-guix/2018-04/msg00070.html > https://bugs.gnu.org/31142 Agreed, these are “regular bugs” that should be fixed. Regarding the “stable” channel, it sounds nice, but again we need machinery to do automatic merging from master to stable when things are built (if I remember Julien’s proposal correctly.) I don’t know, I’m not entirely sure how this could happen. :-) > - TeXlive... (sigh!) Oh right, definitely something we need for 1.0! It’s great that you already started looking at importing more packages from TeXLive, even if that turns out to be incredibly tricky. Then we’ll need a profile hook so people have the option to directly install individual texlive packages in their profile. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-30 5:08 ` Chris Marusich 2018-07-30 7:33 ` Pierre Neidhardt @ 2018-08-19 11:11 ` Ludovic Courtès 2018-08-20 1:12 ` Chris Marusich 1 sibling, 1 reply; 44+ messages in thread From: Ludovic Courtès @ 2018-08-19 11:11 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel Hi Chris, Chris Marusich <cmmarusich@gmail.com> skribis: > At the moment, I only have this to add: It would be nice if we could > decide on how we will use version numbers going forward and publish a > description of that in the manual or on the website. > > I think the important thing is that we publish a description. The > details of it are less important. We can use Semantic Versioning [1], > Sentimental Versioning [2], or something totally different. As long as > we publish our decision and stick to it, everyone will know what to > expect. Good point! The difficulty here is that Guix is effectively a large collection of libraries, which makes it hard to map it to the semver story, I think. Or to put it differently, we should map to semver in an “abstract way”: what semver refers to as “API changes” would rather be important CLI/API changes. Thoughts? Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-19 11:11 ` Ludovic Courtès @ 2018-08-20 1:12 ` Chris Marusich 2018-08-30 19:34 ` Ricardo Wurmus 0 siblings, 1 reply; 44+ messages in thread From: Chris Marusich @ 2018-08-20 1:12 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 2426 bytes --] Hi Ludo, ludo@gnu.org (Ludovic Courtès) writes: > Chris Marusich <cmmarusich@gmail.com> skribis: > >> At the moment, I only have this to add: It would be nice if we could >> decide on how we will use version numbers going forward and publish a >> description of that in the manual or on the website. >> >> I think the important thing is that we publish a description. The >> details of it are less important. We can use Semantic Versioning [1], >> Sentimental Versioning [2], or something totally different. As long as >> we publish our decision and stick to it, everyone will know what to >> expect. > > Good point! The difficulty here is that Guix is effectively a large > collection of libraries, which makes it hard to map it to the semver > story, I think. Or to put it differently, we should map to semver in an > “abstract way”: what semver refers to as “API changes” would rather be > important CLI/API changes. > > Thoughts? I spoke of version numbers, but what I really meant to say is that for 1.0 and beyond we should clearly set expectations regarding stability. By properly setting expectations, we can avoid surprises and improve the experience for people using Guix, especially people trying Guix for the first time. The version number scheme is just one aspect of that. I'm not advocating that we change anything; I'm only advocating that we should make our stability promise (if any) clear by documenting it. If you want to know my thoughts about what sort of stability promise we should provide, I'd be happy to talk about that also, but here I'm only saying that we should provide a promise. The details of the promise are less important. If you agree, then perhaps we can proceed along the following lines: 1) Discuss what our stability promise should be. It might be that we decide to simply stick with the status quo and document it. But whatever the result, it should be something that hopefully everyone agrees on (especially maintainers and contributors). 2) Document it. Put it on the website, in the manual, etc. 3) Follow it. Mention it in the Contributing section of the manual, the README, etc., and require people to adhere to it when making changes. As a maintainer, what do you think? Does it makes sense for the Guix project to set expectations by documenting our stability promise? -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-20 1:12 ` Chris Marusich @ 2018-08-30 19:34 ` Ricardo Wurmus 0 siblings, 0 replies; 44+ messages in thread From: Ricardo Wurmus @ 2018-08-30 19:34 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel Hi Chris, > I'm not advocating that we change anything; I'm only advocating that we > should make our stability promise (if any) clear by documenting it. If > you want to know my thoughts about what sort of stability promise we > should provide, I'd be happy to talk about that also, but here I'm only > saying that we should provide a promise. The details of the promise are > less important. > > If you agree, then perhaps we can proceed along the following lines: > > 1) Discuss what our stability promise should be. It might be that we > decide to simply stick with the status quo and document it. But > whatever the result, it should be something that hopefully everyone > agrees on (especially maintainers and contributors). > > 2) Document it. Put it on the website, in the manual, etc. > > 3) Follow it. Mention it in the Contributing section of the manual, the > README, etc., and require people to adhere to it when making changes. > > As a maintainer, what do you think? Does it makes sense for the Guix > project to set expectations by documenting our stability promise? This is difficult. The version jump signalizes that Guix is ready for “productive” use; it really merely adjusts the version number in accordance with how the community has been using Guix. I’d be wary of putting something more than that in writing. 1.0 means “this works pretty well” and “you shouldn’t expect sudden large changes to how this works”. I’d like to leave the discussion of a stability promise to a time when we decide to maintain a “stable” branch. The other kind of stability applies only to using Guix as a library, which I don’t think is a very popular use outside of Guix itself. -- Ricardo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès 2018-07-30 1:23 ` Pjotr Prins 2018-07-30 5:08 ` Chris Marusich @ 2018-08-19 21:52 ` Amirouche Boubekki 2018-08-20 7:44 ` Ricardo Wurmus 2018-09-04 22:55 ` fis trivial 3 siblings, 1 reply; 44+ messages in thread From: Amirouche Boubekki @ 2018-08-19 21:52 UTC (permalink / raw) To: ludo; +Cc: guix-devel, Guix-devel Hello everyone, On 2018-07-29 17:18, ludo@gnu.org wrote: > Hello Guix! > > I’ve pushed to guix/maintenance.git a list of things that IMO we should > do or might want to do for 1.0, with the understanding that 1.0 should > happen in 2018 (or early 2019 at the latest!). :-) > > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org > I see no mention of containers. What is the status and goal about that subject? -- Amirouche ~ amz3 ~ http://www.hyperdev.fr ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-19 21:52 ` Amirouche Boubekki @ 2018-08-20 7:44 ` Ricardo Wurmus 2018-08-29 16:05 ` Amirouche Boubekki 0 siblings, 1 reply; 44+ messages in thread From: Ricardo Wurmus @ 2018-08-20 7:44 UTC (permalink / raw) To: Amirouche Boubekki; +Cc: guix-devel, Guix-devel Amirouche Boubekki <amirouche@hypermove.net> writes: >> I’ve pushed to guix/maintenance.git a list of things that IMO we should >> do or might want to do for 1.0, with the understanding that 1.0 should >> happen in 2018 (or early 2019 at the latest!). :-) >> >> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org >> > > I see no mention of containers. What is the status and goal about that > subject? What feature regarding containers would you like to know more about? “guix environment”, for example, supports isolation through container features. -- Ricardo ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-08-20 7:44 ` Ricardo Wurmus @ 2018-08-29 16:05 ` Amirouche Boubekki 0 siblings, 0 replies; 44+ messages in thread From: Amirouche Boubekki @ 2018-08-29 16:05 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel, guix-devel-bounces+amirouche=hypermove.net [-- Attachment #1: Type: text/plain, Size: 1135 bytes --] Le lun. 20 août 2018 à 09:45, Ricardo Wurmus <rekado@elephly.net> a écrit : > > Amirouche Boubekki <amirouche@hypermove.net> writes: > > >> I’ve pushed to guix/maintenance.git a list of things that IMO we should > >> do or might want to do for 1.0, with the understanding that 1.0 should > >> happen in 2018 (or early 2019 at the latest!). :-) > >> > >> > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org > >> > > > > I see no mention of containers. What is the status and goal about that > > subject? > > What feature regarding containers would you like to know more about? > Thanks for your reply. I use containers (via LXC) as lightweight Virtual Machines as such I can emulate my use of LXC with guix already using a VM. The difference I see between guix containers and LXC is that in LXC the container has its own network device and an IP. What I usually do with LXC: a) start the lxc container b) ssh into it and proceed as if I was in a Xen Virtuam Machine. Have nice day! > > “guix environment”, for example, supports isolation through container > [-- Attachment #2: Type: text/html, Size: 1957 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès ` (2 preceding siblings ...) 2018-08-19 21:52 ` Amirouche Boubekki @ 2018-09-04 22:55 ` fis trivial 2018-09-04 23:09 ` Adam Van Ymeren 3 siblings, 1 reply; 44+ messages in thread From: fis trivial @ 2018-09-04 22:55 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel@gnu.org Ludovic Courtès writes: > Hello Guix! > > I’ve pushed to guix/maintenance.git a list of things that IMO we should > do or might want to do for 1.0, with the understanding that 1.0 should > happen in 2018 (or early 2019 at the latest!). :-) > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org > > The list focuses on “big item” features and tasks, omitting routine bug > fixes and improvements. Some of these items don’t require a lot of work > or expertise though, so hopefully there’s enough on everyone’s plate. > > Feel free to comment, volunteer, add items (but not too many!), remove > items, promote items, etc. Committers should feel free to edit the file > directly in maintenance.git, especially to mark things as done. ;-) > > Copy of the file attached below. > > Ludo’. > > PS: I’m starting the discussion but will go AFK soon after sending this > message. :-) Hi Ludovic, For near future version of GUIX, maybe 1.1, would it be possible to: Upgrade to latest GCC as base compiler Use gold linker as default Based on experience, newer GCC and gold linker could reduce compilation time and memory requirement dramatically. It would be beneficial to both build farm which have heavy load and laptop users who have very limited memory. Thanks. -- Jiaming ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Roadmap for Guix 1.0 2018-09-04 22:55 ` fis trivial @ 2018-09-04 23:09 ` Adam Van Ymeren 0 siblings, 0 replies; 44+ messages in thread From: Adam Van Ymeren @ 2018-09-04 23:09 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel@gnu.org [-- Attachment #1: Type: text/plain, Size: 2121 bytes --] Kinda late to the party here but I think a goal for 1.0 should be to ensure every single package builds on x86_64 and/or i686 and that most substitutes are available at the time of release. Having guix claim to have packages which then fail to build can leave a poor first impression. It's fine for alpha/beta but I think it will be really important for 1.0 to feel as robust as possible. I'd even say that any packages which don't build for 1.0 should be deleted or at least hidden. Maybe of channels happen we could use a stable vs unstable channels. That's my 2 cents on 1.0 at least. On September 4, 2018 6:55:57 PM EDT, fis trivial <ybbs.daans@hotmail.com> wrote: > >Ludovic Courtès writes: > >> Hello Guix! >> >> I’ve pushed to guix/maintenance.git a list of things that IMO we >should >> do or might want to do for 1.0, with the understanding that 1.0 >should >> happen in 2018 (or early 2019 at the latest!). :-) >> >> >https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org >> >> The list focuses on “big item” features and tasks, omitting routine >bug >> fixes and improvements. Some of these items don’t require a lot of >work >> or expertise though, so hopefully there’s enough on everyone’s plate. >> >> Feel free to comment, volunteer, add items (but not too many!), >remove >> items, promote items, etc. Committers should feel free to edit the >file >> directly in maintenance.git, especially to mark things as done. ;-) >> >> Copy of the file attached below. >> >> Ludo’. >> >> PS: I’m starting the discussion but will go AFK soon after sending >this >> message. :-) > >Hi Ludovic, > >For near future version of GUIX, maybe 1.1, would it be possible to: > > Upgrade to latest GCC as base compiler > > Use gold linker as default > >Based on experience, newer GCC and gold linker could reduce compilation >time >and memory requirement dramatically. It would be beneficial to both >build >farm which have heavy load and laptop users who have very limited >memory. > >Thanks. >-- >Jiaming [-- Attachment #2: Type: text/html, Size: 2601 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* LVM support @ 2015-04-15 5:07 Tomáš Čech 2015-04-15 12:32 ` Ludovic Courtès 0 siblings, 1 reply; 44+ messages in thread From: Tomáš Čech @ 2015-04-15 5:07 UTC (permalink / raw) To: guix-devel Hi Guix, as project for my Hackweek in SUSE I decided to spend my time on LVM support in GuixSD - something I miss greatly. This also means that I'll have much less time for that after this week :( So far I spent time on reviving my GuixSD installation and preparing staticly linked binaries for initrd. I have now lvm2 package with extra output "static". What next? Now the simplest way would be to simply call vgchange --activate y Matching configuration could be one configuration option: (use-lvm?) That would scan all block devices and look for LVM signature. Pros: - it's super simple! Cons: - if LVM with filesystem required at boot-time is not found, error is not detected or returned by LVM itself Slightly bit more complicated way could be vgchange --activate y <volume_group_name> for every volume group defined in system configuration. Matching configuration could be (logical-volume-groups '("system" "data")) e.g. specify list of volume group names used by system. Pros: - still simple - if group activation fails, I can detect it and report it to user Cons: - some block devices with LVM may not be available at boot-time (like iSCSI devices accessible through network only or Luks devices available after entering password) That is my current approach. I could also specify whether it should be made available at boot time or not (logical-volume-groups '('("system" #t) '("data" #f))) (sorry for my poor Scheme taste here :) Pros: - with this I could say that volume group "system" should be activated at boot time, but "data" should be activated later. Cons: - starting to be more complicated - I need both initrd stage LVM activation and root filesystem stage LVM activation (implemented as service? which dependencies it has?) Or do it in different way. I'd rather not propose here any wild ideas for configuration but if you can devise something better, please tell me... S_W ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-04-15 5:07 LVM support Tomáš Čech @ 2015-04-15 12:32 ` Ludovic Courtès 2015-04-16 6:24 ` Tomáš Čech 0 siblings, 1 reply; 44+ messages in thread From: Ludovic Courtès @ 2015-04-15 12:32 UTC (permalink / raw) To: guix-devel Tomáš Čech <sleep_walker@gnu.org> skribis: > as project for my Hackweek in SUSE I decided to spend my time on LVM > support in GuixSD - something I miss greatly. This also means that > I'll have much less time for that after this week :( Well this is nice already! > So far I spent time on reviving my GuixSD installation and preparing > staticly linked binaries for initrd. I have now lvm2 package with > extra output "static". Don’t worry about static linking or anything: you can use any package, including dynamically-linked, and it will be magically added to the initrd if needed. Then as a second step, since that’ll probably be very big, you can work on statically-linked variants of the relevant packages (as done for ‘e2fsck/static’.) > Now the simplest way would be to simply call > > vgchange --activate y > > Matching configuration could be one configuration option: > (use-lvm?) > > > That would scan all block devices and look for LVM signature. > > Pros: > - it's super simple! > Cons: > - if LVM with filesystem required at boot-time is not found, error > is not detected or returned by LVM itself > > > > Slightly bit more complicated way could be > > vgchange --activate y <volume_group_name> > > for every volume group defined in system configuration. Matching configuration could be > (logical-volume-groups '("system" "data")) > > e.g. specify list of volume group names used by system. > > Pros: > - still simple > - if group activation fails, I can detect it and report it to user > > Cons: > - some block devices with LVM may not be available at boot-time (like > iSCSI devices accessible through network only or Luks devices > available after entering password) > > That is my current approach. > > > > I could also specify whether it should be made available at boot time or not > (logical-volume-groups '('("system" #t) > '("data" #f))) > > (sorry for my poor Scheme taste here :) > > Pros: > - with this I could say that volume group "system" should be activated > at boot time, but "data" should be activated later. > > Cons: > - starting to be more complicated - I need both initrd stage LVM > activation and root filesystem stage LVM activation (implemented as > service? which dependencies it has?) Sorry I’m not really familiar with LVM. Technically, if LVM volumes are mapped devices, the best would be to define a <mapped-device-kind> structure for them, as discussed on IRC (like ‘luks-device-mapping’ in (gnu system).) Then users would need to adjust their ‘mapped-devices’ accordingly (info "(guix) Mapped Devices"). How does that sound? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-04-15 12:32 ` Ludovic Courtès @ 2015-04-16 6:24 ` Tomáš Čech 2015-04-16 12:47 ` Ludovic Courtès 0 siblings, 1 reply; 44+ messages in thread From: Tomáš Čech @ 2015-04-16 6:24 UTC (permalink / raw) To: guix-devel On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote: >Tomáš Čech <sleep_walker@gnu.org> skribis: > >> as project for my Hackweek in SUSE I decided to spend my time on LVM >> support in GuixSD - something I miss greatly. This also means that >> I'll have much less time for that after this week :( > >Well this is nice already! > >> So far I spent time on reviving my GuixSD installation and preparing >> staticly linked binaries for initrd. I have now lvm2 package with >> extra output "static". > >Don’t worry about static linking or anything: you can use any package, >including dynamically-linked, and it will be magically added to the >initrd if needed. > >Then as a second step, since that’ll probably be very big, you can work >on statically-linked variants of the relevant packages (as done for >‘e2fsck/static’.) I did this already :) > >> Now the simplest way would be to simply call >> >> vgchange --activate y >> >> Matching configuration could be one configuration option: >> (use-lvm?) >> >> >> That would scan all block devices and look for LVM signature. >> >> Pros: >> - it's super simple! >> Cons: >> - if LVM with filesystem required at boot-time is not found, error >> is not detected or returned by LVM itself >> >> >> >> Slightly bit more complicated way could be >> >> vgchange --activate y <volume_group_name> >> >> for every volume group defined in system configuration. Matching configuration could be >> (logical-volume-groups '("system" "data")) >> >> e.g. specify list of volume group names used by system. >> >> Pros: >> - still simple >> - if group activation fails, I can detect it and report it to user >> >> Cons: >> - some block devices with LVM may not be available at boot-time (like >> iSCSI devices accessible through network only or Luks devices >> available after entering password) >> >> That is my current approach. >> >> >> >> I could also specify whether it should be made available at boot time or not >> (logical-volume-groups '('("system" #t) >> '("data" #f))) >> >> (sorry for my poor Scheme taste here :) >> >> Pros: >> - with this I could say that volume group "system" should be activated >> at boot time, but "data" should be activated later. >> >> Cons: >> - starting to be more complicated - I need both initrd stage LVM >> activation and root filesystem stage LVM activation (implemented as >> service? which dependencies it has?) > >Sorry I’m not really familiar with LVM. It's implemented using device mapper but instead of mapping one block device to another you map one block device to whole group (like playground where you can do anything). > >Technically, if LVM volumes are mapped devices, the best would be to >define a <mapped-device-kind> structure for them, as discussed on IRC >(like ‘luks-device-mapping’ in (gnu system).) I didn't like the idea first because it felt confusing and unatural. Words like `mapping' and `source' and `target' are misleading. But from programming POV it seems to be the easisest approach in the end. (define-record-type* <mapped-device> mapped-device make-mapped-device mapped-device? (source mapped-device-source) ;string (target mapped-device-target) ;string (type mapped-device-type)) ;<mapped-device-kind> `source' will be ignored (I not only don't need it but I don't even know how to pass it or what it should do). `target' will be used for volume group name. mapped-device-kind structure is easily applicable. On the other hand problem starts with need-for-boot?. Device mapped device will be activated during the boot (which is desirable for LVM) only if there is filesystem which uses such device and has `need-for-boot?' set to #t. I needed to tweak operating-system-boot-mapped-devices to not filter mappings of the new type at all. Now it seems to generate initrd capable of booting root filesystem from LVM :) The thing is that this design is not nice. I always admired Scheme's power in expressing things naturally. mapped-device interface is for mapping 1 block device to 1 block device which will contain 1 filesystem. Design I'm thinking about would follow file-system structure. For device property (I'm not sure if this is proper word in Scheme for item of record type) to define functions like `partition' (disk, number), `mapped-device' (source, target, type), `logical-volume' (group, volume) and whatever would be needed further. You could then express your mount in more powerful way like: (partition "sda" 1) (mapped-device (partition "sda" 2) "encrypted_swap" luks-mapping-type) (logical-volume "system_group" "root") (mapped-device (logical-volume "some_group" "some_volume") "encrypted data" luks-mapping-type) etc. Of course, it would lead to more complicated code to handle such configuration, but it would definitely feel more natural. When other block device type (like iSCSI) would be required, just another function (or whatever it is) would be implemented. Please don't tell me 'this is not how Guix works' :) Best regards, S_W ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-04-16 6:24 ` Tomáš Čech @ 2015-04-16 12:47 ` Ludovic Courtès 2015-04-17 1:09 ` Tomáš Čech 0 siblings, 1 reply; 44+ messages in thread From: Ludovic Courtès @ 2015-04-16 12:47 UTC (permalink / raw) To: guix-devel Tomáš Čech <sleep_walker@gnu.org> skribis: > On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote: [...] >>Sorry I’m not really familiar with LVM. > > It's implemented using device mapper but instead of mapping one block > device to another you map one block device to whole group (like > playground where you can do anything). What do you mean by “whole group”? A tree under /dev/mapper? >>Technically, if LVM volumes are mapped devices, the best would be to >>define a <mapped-device-kind> structure for them, as discussed on IRC >>(like ‘luks-device-mapping’ in (gnu system).) > > I didn't like the idea first because it felt confusing and > unatural. Words like `mapping' and `source' and `target' are > misleading. But from programming POV it seems to be the easisest > approach in the end. I would think the terms are pretty descriptive, esp. when looking at the corresponding section of the manual, but I’m biased. ;-) Now, my understanding of your message is not so much that the terms are misleading, but rather that the abstraction is bogus (which appears to be the case based on what you say.) > On the other hand problem starts with need-for-boot?. Device mapped > device will be activated during the boot (which is desirable for LVM) > only if there is filesystem which uses such device and has > `need-for-boot?' set to #t. Right. I was hesitant about this approach actually, see 9cb426b8. > I needed to tweak operating-system-boot-mapped-devices to not filter > mappings of the new type at all. Now it seems to generate initrd > capable of booting root filesystem from LVM :) Nice! Could you post your working version of the patch, just to make things more concrete? > The thing is that this design is not nice. I always admired Scheme's > power in expressing things naturally. mapped-device interface is for > mapping 1 block device to 1 block device which will contain 1 > filesystem. Understood. This has nothing to do with Scheme, really. :-) > Design I'm thinking about would follow file-system structure. For > device property (I'm not sure if this is proper word in Scheme for > item of record type) to define functions like `partition' (disk, > number), `mapped-device' (source, target, type), `logical-volume' (group, > volume) and whatever would be needed further. You could then express > your mount in more powerful way like: > > (partition "sda" 1) > > (mapped-device > (partition "sda" 2) > "encrypted_swap" > luks-mapping-type) > > (logical-volume > "system_group" > "root") > > > (mapped-device > (logical-volume "some_group" "some_volume") > "encrypted data" > luks-mapping-type) > > etc. I see. Looks good! Does the volume some_group/some_volume have an associated /dev node or tree? What does it look like? Really a detail, but I think "/dev/sda2" or (partition "/dev/sda2") is enough; no need to abstract it, IMO, since device node name is up to the user. > Of course, it would lead to more complicated code to handle such > configuration, but it would definitely feel more natural. > > When other block device type (like iSCSI) would be required, just > another function (or whatever it is) would be implemented. Anything special about iSCSI? I would expect iSCSI partitions/disks to just have block devices as usual, no? Thank you! Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-04-16 12:47 ` Ludovic Courtès @ 2015-04-17 1:09 ` Tomáš Čech 2015-04-21 15:52 ` Ludovic Courtès 0 siblings, 1 reply; 44+ messages in thread From: Tomáš Čech @ 2015-04-17 1:09 UTC (permalink / raw) To: guix-devel [-- Attachment #1.1: Type: text/plain, Size: 5200 bytes --] On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote: >Tomáš Čech <sleep_walker@gnu.org> skribis: > >> On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote: > >[...] > >>>Sorry I’m not really familiar with LVM. >> >> It's implemented using device mapper but instead of mapping one block >> device to another you map one block device to whole group (like >> playground where you can do anything). > >What do you mean by “whole group”? A tree under /dev/mapper? From device node POV it generates /dev/<volume_group_name>/<logical_volume_name> and it also creates /dev/mapper/<volume_group_name>-<logical_volume_name> and /dev/dm-<number>. From block device perspective it adds another level of "partitioning" to "physical volume" partitions. You gather block devices (can be partitions, disks, anything), create volume group to join the space into one entity and then create logical volumes without caring where it really is. Logical volumes are useful for resizing, adding and removing filesystems - it has always the same device node. > >>>Technically, if LVM volumes are mapped devices, the best would be to >>>define a <mapped-device-kind> structure for them, as discussed on IRC >>>(like ‘luks-device-mapping’ in (gnu system).) >> >> I didn't like the idea first because it felt confusing and >> unatural. Words like `mapping' and `source' and `target' are >> misleading. But from programming POV it seems to be the easisest >> approach in the end. > >I would think the terms are pretty descriptive, esp. when looking at the >corresponding section of the manual, but I’m biased. ;-) I meant in LVM context of course. >Now, my understanding of your message is not so much that the terms are >misleading, but rather that the abstraction is bogus (which appears to >be the case based on what you say.) > >> On the other hand problem starts with need-for-boot?. Device mapped >> device will be activated during the boot (which is desirable for LVM) >> only if there is filesystem which uses such device and has >> `need-for-boot?' set to #t. > >Right. I was hesitant about this approach actually, see 9cb426b8. Ah, OK, I didn't updated since I started to work on LVM. >> I needed to tweak operating-system-boot-mapped-devices to not filter >> mappings of the new type at all. Now it seems to generate initrd >> capable of booting root filesystem from LVM :) > >Nice! Could you post your working version of the patch, just to make >things more concrete? I attach patch to this mail. >> The thing is that this design is not nice. I always admired Scheme's >> power in expressing things naturally. mapped-device interface is for >> mapping 1 block device to 1 block device which will contain 1 >> filesystem. > >Understood. This has nothing to do with Scheme, really. :-) > >> Design I'm thinking about would follow file-system structure. For >> device property (I'm not sure if this is proper word in Scheme for >> item of record type) to define functions like `partition' (disk, >> number), `mapped-device' (source, target, type), `logical-volume' (group, >> volume) and whatever would be needed further. You could then express >> your mount in more powerful way like: >> >> (partition "sda" 1) >> >> (mapped-device >> (partition "sda" 2) >> "encrypted_swap" >> luks-mapping-type) >> >> (logical-volume >> "system_group" >> "root") >> >> >> (mapped-device >> (logical-volume "some_group" "some_volume") >> "encrypted data" >> luks-mapping-type) >> >> etc. > >I see. Looks good! > >Does the volume some_group/some_volume have an associated /dev node or >tree? What does it look like? Yes, it does, I described above. >Really a detail, but I think "/dev/sda2" or (partition "/dev/sda2") is >enough; no need to abstract it, IMO, since device node name is up to the >user. Well, I faced situations where such freedom of expression would be handy, but there were rare. sda says that it is the first found scsi device in the system but it doesn't say anything about accessibility of the device (`local-disk' should be introduced as well I think). >> Of course, it would lead to more complicated code to handle such >> configuration, but it would definitely feel more natural. >> >> When other block device type (like iSCSI) would be required, just >> another function (or whatever it is) would be implemented. > >Anything special about iSCSI? I would expect iSCSI partitions/disks to >just have block devices as usual, no? Yes, but when you have root filesystem on iSCSI, you need to perform other actions to make that block device available as with device mapping or LVM... (You need to configure and establish connection to iSCSI target.) Ad the progress - current state of the patch is that it should work for filesystems mounted from initrd. And is ugly. As I understand the problem, created device nodes are missing after switch-root and it seems it tried to mount filesystems before starting eudev. I'll have a look on that again after some sleep. Thank you for your comments. S_W [-- Attachment #1.2: lvm.patch --] [-- Type: text/plain, Size: 5818 bytes --] diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm index caec80f..18d1f06 100644 --- a/gnu/packages/linux.scm +++ b/gnu/packages/linux.scm @@ -1638,6 +1638,33 @@ mapper. Kernel components are part of Linux-libre.") ;; Command-line tools are GPLv2. (license (list gpl2 lgpl2.1)))) +(define-public lvm2/static + (package + (name "lvm2-static") + (version (package-version lvm2)) + (build-system trivial-build-system) + (source #f) + (arguments + `(#:modules ((guix build utils)) + #:builder + (begin + (use-modules (guix build utils)) + (let ((source (string-append (assoc-ref %build-inputs "lvm2") "/sbin")) + (bin (string-append (assoc-ref %outputs "out") "/sbin"))) + (mkdir-p bin) + (for-each (lambda (file) + (copy-file (string-append source "/" file) + (string-append bin "/" file))) + '("lvm.static" "dmsetup.static")))))) + + (native-inputs `(("lvm2" ,lvm2 "static"))) + (synopsis "Statically-linked commands from lvm2") + (description + "This package provides statically-linked binaries dmsetup and lvm taken +from lvm2 package. It is meant to be used in initrds.") + (home-page (package-home-page lvm2)) + (license (package-license lvm2)))) + (define-public wireless-tools (package (name "wireless-tools") diff --git a/gnu/system.scm b/gnu/system.scm index 6cf12df..7c1e67c 100644 --- a/gnu/system.scm +++ b/gnu/system.scm @@ -41,6 +41,7 @@ #:use-module (gnu packages compression) #:use-module (gnu packages firmware) #:autoload (gnu packages cryptsetup) (cryptsetup) + #:autoload (gnu packages linux) (lvm2/static) #:use-module (gnu services) #:use-module (gnu services dmd) #:use-module (gnu services base) @@ -86,7 +87,9 @@ %base-packages %base-firmware - luks-device-mapping)) + luks-device-mapping + lvm-mapping + lvm-mapping-used?)) ;;; Commentary: ;;; @@ -208,6 +211,27 @@ file." (open open-luks-device) (close close-luks-device))) +(define (logical-volume-group-activate source target) + #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static") + "vgchange" "--activate" "y" #$target))) + +(define (logical-volume-group-deactivate source target) + #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static") + "vgchange" "--activate" "n" #$target))) + +(define (lvm-mapping-used? devices) + (not + (null? (filter + (lambda (md) + (eq? (mapped-device-type md) + lvm-mapping)) + devices)))) + +(define lvm-mapping + (mapped-device-kind + (open logical-volume-group-activate) + (close logical-volume-group-deactivate))) + (define (other-file-system-services os) "Return file system services for the file systems of OS that are not marked as 'needed-for-boot'." @@ -267,7 +291,10 @@ from the initrd." (file-systems (operating-system-file-systems os))) (filter (lambda (md) (let ((user (mapped-device-user md file-systems))) - (and user (file-system-needed-for-boot? user)))) + (or + (and user (file-system-needed-for-boot? user)) + (and (eq? (mapped-device-type md) + lvm-mapping))))) devices))) (define (device-mapping-services os) diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm index 83685ad..fc8bbd3 100644 --- a/gnu/system/linux-initrd.scm +++ b/gnu/system/linux-initrd.scm @@ -25,6 +25,7 @@ #:select (%store-prefix)) #:use-module ((guix derivations) #:select (derivation->output-path)) + #:use-module (gnu system) #:use-module (gnu packages cpio) #:use-module (gnu packages compression) #:use-module (gnu packages linux) @@ -212,6 +213,9 @@ loaded at boot time in the order in which they appear." file-systems) (list e2fsck/static) '()) + ,@(if (lvm-mapping-used? mapped-devices) + (list lvm2/static) + '()) ,@(if volatile-root? (list unionfs-fuse/static) '()))) @@ -241,7 +245,19 @@ loaded at boot time in the order in which they appear." (boot-system #:mounts '#$(map file-system->spec file-systems) #:pre-mount (lambda () - (and #$@device-mapping-commands)) + (and #$@device-mapping-commands + ;; If we activated any volume group, we + ;; need to ensure that device nodes are + ;; created. Add code here to call it + ;; once for all activations. + #$(when (lvm-mapping-used? mapped-devices) + #~(zero? + (system* (string-append + #$lvm2/static + "/sbin/lvm.static") + "vgscan" + "--mknodes"))))) + #:linux-modules '#$linux-modules #:linux-module-directory '#$kodir #:qemu-guest-networking? #$qemu-networking? [-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: LVM support 2015-04-17 1:09 ` Tomáš Čech @ 2015-04-21 15:52 ` Ludovic Courtès 2015-05-01 11:32 ` Tomáš Čech 0 siblings, 1 reply; 44+ messages in thread From: Ludovic Courtès @ 2015-04-21 15:52 UTC (permalink / raw) To: guix-devel Tomáš Čech <sleep_walker@gnu.org> skribis: > On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote: >>Tomáš Čech <sleep_walker@gnu.org> skribis: >> >>> On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote: >> >>[...] >> >>>>Sorry I’m not really familiar with LVM. >>> >>> It's implemented using device mapper but instead of mapping one block >>> device to another you map one block device to whole group (like >>> playground where you can do anything). >> >>What do you mean by “whole group”? A tree under /dev/mapper? > > From device node POV it generates > /dev/<volume_group_name>/<logical_volume_name> and it also creates > /dev/mapper/<volume_group_name>-<logical_volume_name> and > /dev/dm-<number>. OK. > From block device perspective it adds another level of "partitioning" > to "physical volume" partitions. You gather block devices (can be > partitions, disks, anything), create volume group to join the space > into one entity and then create logical volumes without caring where > it really is. Logical volumes are useful for resizing, adding and > removing filesystems - it has always the same device node. Yes, that part I knew. ;-) [...] > --- a/gnu/system.scm > +++ b/gnu/system.scm > @@ -41,6 +41,7 @@ > #:use-module (gnu packages compression) > #:use-module (gnu packages firmware) > #:autoload (gnu packages cryptsetup) (cryptsetup) > + #:autoload (gnu packages linux) (lvm2/static) > #:use-module (gnu services) > #:use-module (gnu services dmd) > #:use-module (gnu services base) > @@ -86,7 +87,9 @@ > %base-packages > %base-firmware > > - luks-device-mapping)) > + luks-device-mapping > + lvm-mapping > + lvm-mapping-used?)) > > ;;; Commentary: > ;;; > @@ -208,6 +211,27 @@ file." > (open open-luks-device) > (close close-luks-device))) > > +(define (logical-volume-group-activate source target) > + #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static") > + "vgchange" "--activate" "y" #$target))) > + > +(define (logical-volume-group-deactivate source target) > + #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static") > + "vgchange" "--activate" "n" #$target))) > + > +(define (lvm-mapping-used? devices) > + (not > + (null? (filter > + (lambda (md) > + (eq? (mapped-device-type md) > + lvm-mapping)) > + devices)))) > + > +(define lvm-mapping > + (mapped-device-kind > + (open logical-volume-group-activate) > + (close logical-volume-group-deactivate))) This looks good to me! So I would declare (mapped-device (source "/dev/sda") (target "volume_group_name-logical_volume_name") (kind lvm-device-mapping)) and that would give me /dev/mapper/volume_group_name-logical_volume_name, right? > (define (other-file-system-services os) > "Return file system services for the file systems of OS that are not marked > as 'needed-for-boot'." > @@ -267,7 +291,10 @@ from the initrd." > (file-systems (operating-system-file-systems os))) > (filter (lambda (md) > (let ((user (mapped-device-user md file-systems))) > - (and user (file-system-needed-for-boot? user)))) > + (or > + (and user (file-system-needed-for-boot? user)) > + (and (eq? (mapped-device-type md) > + lvm-mapping))))) > devices))) I don’t think it’s necessary: if a ‘file-system’ object has "/dev/mapper/volume_group_name-logical_volume_name" has its ‘device’ field, then this device mapping will automatically be recognized as needed-for-boot, won’t it? > --- a/gnu/system/linux-initrd.scm > +++ b/gnu/system/linux-initrd.scm > @@ -25,6 +25,7 @@ > #:select (%store-prefix)) > #:use-module ((guix derivations) > #:select (derivation->output-path)) > + #:use-module (gnu system) > #:use-module (gnu packages cpio) > #:use-module (gnu packages compression) > #:use-module (gnu packages linux) > @@ -212,6 +213,9 @@ loaded at boot time in the order in which they appear." > file-systems) > (list e2fsck/static) > '()) > + ,@(if (lvm-mapping-used? mapped-devices) > + (list lvm2/static) > + '()) > ,@(if volatile-root? > (list unionfs-fuse/static) > '()))) > @@ -241,7 +245,19 @@ loaded at boot time in the order in which they appear." > > (boot-system #:mounts '#$(map file-system->spec file-systems) > #:pre-mount (lambda () > - (and #$@device-mapping-commands)) > + (and #$@device-mapping-commands > + ;; If we activated any volume group, we > + ;; need to ensure that device nodes are > + ;; created. Add code here to call it > + ;; once for all activations. > + #$(when (lvm-mapping-used? mapped-devices) > + #~(zero? > + (system* (string-append > + #$lvm2/static > + "/sbin/lvm.static") > + "vgscan" > + "--mknodes"))))) So ‘lvm vgchange --activate y’ does not create /dev nodes? Would it be possible to change the command returned by ‘logical-volume-group-activate’ to somehow create the nodes? That would be ideal. Thanks! Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-04-21 15:52 ` Ludovic Courtès @ 2015-05-01 11:32 ` Tomáš Čech 2015-05-03 19:59 ` Ludovic Courtès 0 siblings, 1 reply; 44+ messages in thread From: Tomáš Čech @ 2015-05-01 11:32 UTC (permalink / raw) To: guix-devel [-- Attachment #1: Type: text/plain, Size: 7229 bytes --] On Tue, Apr 21, 2015 at 05:52:33PM +0200, Ludovic Courtès wrote: >Tomáš Čech <sleep_walker@gnu.org> skribis: > >> On Thu, Apr 16, 2015 at 02:47:52PM +0200, Ludovic Courtès wrote: >>>Tomáš Čech <sleep_walker@gnu.org> skribis: >>> >>>> On Wed, Apr 15, 2015 at 02:32:14PM +0200, Ludovic Courtès wrote: >>> >>>[...] >>> >>>>>Sorry I’m not really familiar with LVM. >>>> >>>> It's implemented using device mapper but instead of mapping one block >>>> device to another you map one block device to whole group (like >>>> playground where you can do anything). >>> >>>What do you mean by “whole group”? A tree under /dev/mapper? >> >> From device node POV it generates >> /dev/<volume_group_name>/<logical_volume_name> and it also creates >> /dev/mapper/<volume_group_name>-<logical_volume_name> and >> /dev/dm-<number>. > >OK. > >> From block device perspective it adds another level of "partitioning" >> to "physical volume" partitions. You gather block devices (can be >> partitions, disks, anything), create volume group to join the space >> into one entity and then create logical volumes without caring where >> it really is. Logical volumes are useful for resizing, adding and >> removing filesystems - it has always the same device node. > >Yes, that part I knew. ;-) > > >[...] > >> --- a/gnu/system.scm >> +++ b/gnu/system.scm >> @@ -41,6 +41,7 @@ >> #:use-module (gnu packages compression) >> #:use-module (gnu packages firmware) >> #:autoload (gnu packages cryptsetup) (cryptsetup) >> + #:autoload (gnu packages linux) (lvm2/static) >> #:use-module (gnu services) >> #:use-module (gnu services dmd) >> #:use-module (gnu services base) >> @@ -86,7 +87,9 @@ >> %base-packages >> %base-firmware >> >> - luks-device-mapping)) >> + luks-device-mapping >> + lvm-mapping >> + lvm-mapping-used?)) >> >> ;;; Commentary: >> ;;; >> @@ -208,6 +211,27 @@ file." >> (open open-luks-device) >> (close close-luks-device))) >> >> +(define (logical-volume-group-activate source target) >> + #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static") >> + "vgchange" "--activate" "y" #$target))) >> + >> +(define (logical-volume-group-deactivate source target) >> + #~(zero? (system* (string-append #$lvm2/static "/sbin/lvm.static") >> + "vgchange" "--activate" "n" #$target))) >> + >> +(define (lvm-mapping-used? devices) >> + (not >> + (null? (filter >> + (lambda (md) >> + (eq? (mapped-device-type md) >> + lvm-mapping)) >> + devices)))) >> + >> +(define lvm-mapping >> + (mapped-device-kind >> + (open logical-volume-group-activate) >> + (close logical-volume-group-deactivate))) > >This looks good to me! > >So I would declare > > (mapped-device > (source "/dev/sda") > (target "volume_group_name-logical_volume_name") > (kind lvm-device-mapping)) > >and that would give me >/dev/mapper/volume_group_name-logical_volume_name, right? Volume group can be on multiple block devices. For now I rely on autodetect abilities of LVM. So you would declare: (mapped-device (source "") ; irrelevant for LVM (target "volume_group_name") (type lvm-mapping)) and that would give you /dev/mapper/volume_group_name-some_volume /dev/mapper/volume_group_name-other_volume ... and more conveniently /dev/volume_group_name/some_volume /dev/volume_group_name/other_volume ... > >> (define (other-file-system-services os) >> "Return file system services for the file systems of OS that are not marked >> as 'needed-for-boot'." >> @@ -267,7 +291,10 @@ from the initrd." >> (file-systems (operating-system-file-systems os))) >> (filter (lambda (md) >> (let ((user (mapped-device-user md file-systems))) >> - (and user (file-system-needed-for-boot? user)))) >> + (or >> + (and user (file-system-needed-for-boot? user)) >> + (and (eq? (mapped-device-type md) >> + lvm-mapping))))) >> devices))) > >I don’t think it’s necessary: if a ‘file-system’ object has >"/dev/mapper/volume_group_name-logical_volume_name" has its ‘device’ >field, then this device mapping will automatically be recognized as >needed-for-boot, won’t it? Yes, you're right, this chunk shouldn't be needed at all. Good catch! >> --- a/gnu/system/linux-initrd.scm >> +++ b/gnu/system/linux-initrd.scm >> @@ -25,6 +25,7 @@ >> #:select (%store-prefix)) >> #:use-module ((guix derivations) >> #:select (derivation->output-path)) >> + #:use-module (gnu system) >> #:use-module (gnu packages cpio) >> #:use-module (gnu packages compression) >> #:use-module (gnu packages linux) >> @@ -212,6 +213,9 @@ loaded at boot time in the order in which they appear." >> file-systems) >> (list e2fsck/static) >> '()) >> + ,@(if (lvm-mapping-used? mapped-devices) >> + (list lvm2/static) >> + '()) >> ,@(if volatile-root? >> (list unionfs-fuse/static) >> '()))) >> @@ -241,7 +245,19 @@ loaded at boot time in the order in which they appear." >> >> (boot-system #:mounts '#$(map file-system->spec file-systems) >> #:pre-mount (lambda () >> - (and #$@device-mapping-commands)) >> + (and #$@device-mapping-commands >> + ;; If we activated any volume group, we >> + ;; need to ensure that device nodes are >> + ;; created. Add code here to call it >> + ;; once for all activations. >> + #$(when (lvm-mapping-used? mapped-devices) >> + #~(zero? >> + (system* (string-append >> + #$lvm2/static >> + "/sbin/lvm.static") >> + "vgscan" >> + "--mknodes"))))) > >So ‘lvm vgchange --activate y’ does not create /dev nodes? Right. >Would it be possible to change the command returned by >‘logical-volume-group-activate’ to somehow create the nodes? That would >be ideal. There are two actions needed to be taken: 1] volume group activation 2] creation of nodes This design choice does as many 1] as needed and 2] once in the end. I could do always 1] and 2] for every volume group, but I didn't find it nice, since previous 2] calls are useless only slowing down the process. Do you really think I should change it? Thanks for your review. S_W [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-05-01 11:32 ` Tomáš Čech @ 2015-05-03 19:59 ` Ludovic Courtès 2015-05-07 8:02 ` Tomáš Čech 0 siblings, 1 reply; 44+ messages in thread From: Ludovic Courtès @ 2015-05-03 19:59 UTC (permalink / raw) To: guix-devel Sorry for the delay. Tomáš Čech <sleep_walker@gnu.org> skribis: > On Tue, Apr 21, 2015 at 05:52:33PM +0200, Ludovic Courtès wrote: [...] >>So I would declare >> >> (mapped-device >> (source "/dev/sda") >> (target "volume_group_name-logical_volume_name") >> (kind lvm-device-mapping)) >> >>and that would give me >>/dev/mapper/volume_group_name-logical_volume_name, right? > > Volume group can be on multiple block devices. For now I rely on autodetect > abilities of LVM. > > So you would declare: > > (mapped-device > (source "") ; irrelevant for LVM > (target "volume_group_name") > (type lvm-mapping)) > > and that would give you > /dev/mapper/volume_group_name-some_volume > /dev/mapper/volume_group_name-other_volume > ... > > and more conveniently > /dev/volume_group_name/some_volume > /dev/volume_group_name/other_volume > ... OK. So the ‘source’ is irrelevant because ‘vgscan’ magically creates the device nodes for volumes such that users don’t have to know what the underlying block devices are, right? [...] >>> (boot-system #:mounts '#$(map file-system->spec file-systems) >>> #:pre-mount (lambda () >>> - (and #$@device-mapping-commands)) >>> + (and #$@device-mapping-commands >>> + ;; If we activated any volume group, we >>> + ;; need to ensure that device nodes are >>> + ;; created. Add code here to call it >>> + ;; once for all activations. >>> + #$(when (lvm-mapping-used? mapped-devices) >>> + #~(zero? >>> + (system* (string-append >>> + #$lvm2/static >>> + "/sbin/lvm.static") >>> + "vgscan" >>> + "--mknodes"))))) >> >>So ‘lvm vgchange --activate y’ does not create /dev nodes? > > Right. > >>Would it be possible to change the command returned by >>‘logical-volume-group-activate’ to somehow create the nodes? That would >>be ideal. > > There are two actions needed to be taken: > 1] volume group activation > 2] creation of nodes > > This design choice does as many 1] as needed and 2] once in the end. > > I could do always 1] and 2] for every volume group, but I didn't find it nice, > since previous 2] calls are useless only slowing down the process. Do you > really think I should change it? No, you’re right, what you did makes a lot of sense (thanks for bearing with me!). Could you send an updated patch? It sounds like we’re almost there, I guess. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-05-03 19:59 ` Ludovic Courtès @ 2015-05-07 8:02 ` Tomáš Čech 2015-05-19 10:32 ` Ludovic Courtès 0 siblings, 1 reply; 44+ messages in thread From: Tomáš Čech @ 2015-05-07 8:02 UTC (permalink / raw) To: guix-devel [-- Attachment #1: Type: text/plain, Size: 3881 bytes --] On Sun, May 03, 2015 at 09:59:53PM +0200, Ludovic Courtès wrote: >Sorry for the delay. Sorry for all the delays :) > >Tomáš Čech <sleep_walker@gnu.org> skribis: > >> On Tue, Apr 21, 2015 at 05:52:33PM +0200, Ludovic Courtès wrote: > >[...] > >>>So I would declare >>> >>> (mapped-device >>> (source "/dev/sda") >>> (target "volume_group_name-logical_volume_name") >>> (kind lvm-device-mapping)) >>> >>>and that would give me >>>/dev/mapper/volume_group_name-logical_volume_name, right? >> >> Volume group can be on multiple block devices. For now I rely on autodetect >> abilities of LVM. >> >> So you would declare: >> >> (mapped-device >> (source "") ; irrelevant for LVM >> (target "volume_group_name") >> (type lvm-mapping)) >> >> and that would give you >> /dev/mapper/volume_group_name-some_volume >> /dev/mapper/volume_group_name-other_volume >> ... >> >> and more conveniently >> /dev/volume_group_name/some_volume >> /dev/volume_group_name/other_volume >> ... > >OK. So the ‘source’ is irrelevant because ‘vgscan’ magically creates >the device nodes for volumes such that users don’t have to know what the >underlying block devices are, right? Yes. >[...] > >>>> (boot-system #:mounts '#$(map file-system->spec file-systems) >>>> #:pre-mount (lambda () >>>> - (and #$@device-mapping-commands)) >>>> + (and #$@device-mapping-commands >>>> + ;; If we activated any volume group, we >>>> + ;; need to ensure that device nodes are >>>> + ;; created. Add code here to call it >>>> + ;; once for all activations. >>>> + #$(when (lvm-mapping-used? mapped-devices) >>>> + #~(zero? >>>> + (system* (string-append >>>> + #$lvm2/static >>>> + "/sbin/lvm.static") >>>> + "vgscan" >>>> + "--mknodes"))))) >>> >>>So ‘lvm vgchange --activate y’ does not create /dev nodes? >> >> Right. >> >>>Would it be possible to change the command returned by >>>‘logical-volume-group-activate’ to somehow create the nodes? That would >>>be ideal. >> >> There are two actions needed to be taken: >> 1] volume group activation >> 2] creation of nodes >> >> This design choice does as many 1] as needed and 2] once in the end. >> >> I could do always 1] and 2] for every volume group, but I didn't find it nice, >> since previous 2] calls are useless only slowing down the process. Do you >> really think I should change it? > >No, you’re right, what you did makes a lot of sense (thanks for bearing >with me!). Good. >Could you send an updated patch? It sounds like we’re almost there, >I guess. Not there yet. Now I need to make some changes with mounting order to help non-root filesystems on LVM volume. Right now it seems it tries to: 1] mount all filesystems 2] run udev But I need to make it: 1] mount /dev 2] run udev service (with the `udevadm settle' in the end) 3] mount the rest of filesystems It seems that /sys and /proc is mounted already from initrd phase using mount-essential-file-systems. Is there reason not to put /dev there as well? I see none so I'll try to add /dev filesystem mounting there (and to move-essential-file-systems) and remove it from %base-file-systems. Best regards, S_W [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: LVM support 2015-05-07 8:02 ` Tomáš Čech @ 2015-05-19 10:32 ` Ludovic Courtès 0 siblings, 0 replies; 44+ messages in thread From: Ludovic Courtès @ 2015-05-19 10:32 UTC (permalink / raw) To: guix-devel Tomáš Čech <sleep_walker@gnu.org> skribis: > On Sun, May 03, 2015 at 09:59:53PM +0200, Ludovic Courtès wrote: [...] >>Could you send an updated patch? It sounds like we’re almost there, >>I guess. > > Not there yet. Now I need to make some changes with mounting order to help > non-root filesystems on LVM volume. > > Right now it seems it tries to: > 1] mount all filesystems > 2] run udev Right. > But I need to make it: > 1] mount /dev > 2] run udev service (with the `udevadm settle' in the end) > 3] mount the rest of filesystems OK. Note that ‘file-system-service’ has a #:requirements parameter, which is where we could pass '(udev). But maybe some of the file systems defined in (gnu system file-systems) need to be mounted before udev is started. You’ll have to try. ;-) > It seems that /sys and /proc is mounted already from initrd phase using > mount-essential-file-systems. Is there reason not to put /dev there as well? The reason to do it this way is that it avoids another special case. That said, in practice /dev is mounted from the initrd because %devtmpfs-file-system has ‘needed-for-boot?’ set. > I see none so I'll try to add /dev filesystem mounting there (and to > move-essential-file-systems) and remove it from %base-file-systems. I don’t think this is necessary. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2018-09-04 23:09 UTC | newest] Thread overview: 44+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès 2018-07-30 1:23 ` Pjotr Prins 2018-07-30 9:02 ` Nils Gillmann 2018-07-30 12:47 ` Pierre Neidhardt 2018-08-19 11:06 ` LVM support Ludovic Courtès 2018-08-29 16:12 ` Roadmap for Guix 1.0 Amirouche Boubekki 2018-08-30 11:46 ` Pierre Neidhardt 2018-08-30 12:04 ` Ludovic Courtès 2018-08-30 12:57 ` Ricardo Wurmus 2018-08-30 14:20 ` Tobias Geerinckx-Rice 2018-08-30 15:17 ` Nils Gillmann 2018-08-30 19:13 ` George Clemmer 2018-08-30 20:12 ` Gábor Boskovits 2018-08-31 14:25 ` George Clemmer 2018-08-31 15:45 ` Vincent Legoll 2018-08-31 15:54 ` Amirouche Boubekki 2018-09-01 7:36 ` rchar01 2018-09-01 9:27 ` Pjotr Prins 2018-09-01 10:09 ` Nils Gillmann 2018-08-30 15:36 ` George Clemmer 2018-08-30 17:11 ` Hartmut Goebel 2018-08-30 18:17 ` Jan Nieuwenhuizen 2018-08-30 21:45 ` Taylan Kammer 2018-07-30 5:08 ` Chris Marusich 2018-07-30 7:33 ` Pierre Neidhardt 2018-08-19 11:19 ` Ludovic Courtès 2018-08-19 11:11 ` Ludovic Courtès 2018-08-20 1:12 ` Chris Marusich 2018-08-30 19:34 ` Ricardo Wurmus 2018-08-19 21:52 ` Amirouche Boubekki 2018-08-20 7:44 ` Ricardo Wurmus 2018-08-29 16:05 ` Amirouche Boubekki 2018-09-04 22:55 ` fis trivial 2018-09-04 23:09 ` Adam Van Ymeren -- strict thread matches above, loose matches on Subject: below -- 2015-04-15 5:07 LVM support Tomáš Čech 2015-04-15 12:32 ` Ludovic Courtès 2015-04-16 6:24 ` Tomáš Čech 2015-04-16 12:47 ` Ludovic Courtès 2015-04-17 1:09 ` Tomáš Čech 2015-04-21 15:52 ` Ludovic Courtès 2015-05-01 11:32 ` Tomáš Čech 2015-05-03 19:59 ` Ludovic Courtès 2015-05-07 8:02 ` Tomáš Čech 2015-05-19 10:32 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.