* IDEA: Give Our Generations a Name
@ 2023-01-16 23:40 jgart
2023-01-17 1:52 ` Csepp
2023-01-17 8:39 ` Simon Tournier
0 siblings, 2 replies; 6+ messages in thread
From: jgart @ 2023-01-16 23:40 UTC (permalink / raw)
To: guix-devel
Hi Guixers,
What do you think if we would be able to give past generations a name?
I'm thinking of the way you can do the following with git:
git stash -m "My description of this important stash."
I think this would help differentiate slight differences that would be hard to tell what the state of that generation was by just looking at the differences of profile package content.
to bloat? or not to bloat? that is the question
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IDEA: Give Our Generations a Name
2023-01-16 23:40 IDEA: Give Our Generations a Name jgart
@ 2023-01-17 1:52 ` Csepp
2023-01-18 18:31 ` Liliana Marie Prikler
2023-01-17 8:39 ` Simon Tournier
1 sibling, 1 reply; 6+ messages in thread
From: Csepp @ 2023-01-17 1:52 UTC (permalink / raw)
To: jgart; +Cc: guix-devel
"jgart" <jgart@dismail.de> writes:
> Hi Guixers,
>
> What do you think if we would be able to give past generations a name?
>
> I'm thinking of the way you can do the following with git:
>
> git stash -m "My description of this important stash."
>
> I think this would help differentiate slight differences that would be
> hard to tell what the state of that generation was by just looking at
> the differences of profile package content.
>
> to bloat? or not to bloat? that is the question
Since generations are just symlinks to profiles in the store and a
profile can be in multiple generations, this would require wrapping the
profile with some additional metadata. I guess it's technically as
simple as adding a "dummy" package that just contains the name in a file
in output/etc/generation-name.txt or something, that would get unioned
into the profile, and then it's a simple matter of outputting that info
in --list-generations.
Right?
I would actually like this for system profiles quite a lot. When you're
working on something like a new file-system or service integration and
have some nondeterministic errors and are trying to track down which
generations reproduce it, it's nice to know in what way generation 24 is
different from generations 15 through 23.
(Also it still sucks that we can't have a single generation with
multiple config variants to choose from at boot, but I digress.)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IDEA: Give Our Generations a Name
2023-01-17 1:52 ` Csepp
@ 2023-01-18 18:31 ` Liliana Marie Prikler
2023-01-19 11:23 ` Csepp
0 siblings, 1 reply; 6+ messages in thread
From: Liliana Marie Prikler @ 2023-01-18 18:31 UTC (permalink / raw)
To: Csepp, jgart; +Cc: guix-devel
Am Dienstag, dem 17.01.2023 um 01:52 +0000 schrieb Csepp:
>
> "jgart" <jgart@dismail.de> writes:
>
> > Hi Guixers,
> >
> > What do you think if we would be able to give past generations a
> > name?
> >
> > I'm thinking of the way you can do the following with git:
> >
> > git stash -m "My description of this important stash."
> >
> > I think this would help differentiate slight differences that would
> > be hard to tell what the state of that generation was by just
> > looking at the differences of profile package content.
> >
> > to bloat? or not to bloat? that is the question
>
> Since generations are just symlinks to profiles in the store and a
> profile can be in multiple generations, this would require wrapping
> the profile with some additional metadata. I guess it's technically
> as simple as adding a "dummy" package that just contains the name in
> a file in output/etc/generation-name.txt or something, that would get
> unioned into the profile, and then it's a simple matter of outputting
> that info in --list-generations.
> Right?
I actually have a better idea. Note how each generation has the name
${common-identifier}-$generation-link. You could thus simply store a
tag by using ${common-identifier}-$tag and simply pointing that at the
right link. Downside is, that you're limited to the "standard"
alphanumeric + dash character set, plus the first character shouldn't
be a number, but I'd say this is good enough for most practical
purposes.
Cheers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IDEA: Give Our Generations a Name
2023-01-18 18:31 ` Liliana Marie Prikler
@ 2023-01-19 11:23 ` Csepp
0 siblings, 0 replies; 6+ messages in thread
From: Csepp @ 2023-01-19 11:23 UTC (permalink / raw)
To: Liliana Marie Prikler; +Cc: Csepp, jgart, guix-devel
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> Am Dienstag, dem 17.01.2023 um 01:52 +0000 schrieb Csepp:
>>
>> "jgart" <jgart@dismail.de> writes:
>>
>> > Hi Guixers,
>> >
>> > What do you think if we would be able to give past generations a
>> > name?
>> >
>> > I'm thinking of the way you can do the following with git:
>> >
>> > git stash -m "My description of this important stash."
>> >
>> > I think this would help differentiate slight differences that would
>> > be hard to tell what the state of that generation was by just
>> > looking at the differences of profile package content.
>> >
>> > to bloat? or not to bloat? that is the question
>>
>> Since generations are just symlinks to profiles in the store and a
>> profile can be in multiple generations, this would require wrapping
>> the profile with some additional metadata. I guess it's technically
>> as simple as adding a "dummy" package that just contains the name in
>> a file in output/etc/generation-name.txt or something, that would get
>> unioned into the profile, and then it's a simple matter of outputting
>> that info in --list-generations.
>> Right?
> I actually have a better idea. Note how each generation has the name
> ${common-identifier}-$generation-link. You could thus simply store a
> tag by using ${common-identifier}-$tag and simply pointing that at the
> right link. Downside is, that you're limited to the "standard"
> alphanumeric + dash character set, plus the first character shouldn't
> be a number, but I'd say this is good enough for most practical
> purposes.
>
> Cheers
Hmm, yup, much simpler.
Although for system generations it doesn't help much, but that could be
handled by setting the name in the OS record.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IDEA: Give Our Generations a Name
2023-01-16 23:40 IDEA: Give Our Generations a Name jgart
2023-01-17 1:52 ` Csepp
@ 2023-01-17 8:39 ` Simon Tournier
1 sibling, 0 replies; 6+ messages in thread
From: Simon Tournier @ 2023-01-17 8:39 UTC (permalink / raw)
To: jgart, guix-devel
Hi,
On Mon, 16 Jan 2023 at 23:40, "jgart" <jgart@dismail.de> wrote:
> What do you think if we would be able to give past generations a name?
Well, I think this would be difficult. And personally I do not have the
use case.
However, be able to locally Git tag and use this tag with “guix
time-machine” will be very handy. :-) Well, it is already possible but
a bit convoluted. It could be nice to do:
guix git tag foobar <commit>
guix time-machine --commit=foobar -- bla
It was one of the idea behind [1] but the code never landed master…
because I have been lazy. ;-)
1: <https://guix.gnu.org/en/blog/2020/add-a-subcommand-showing-gnu-guix-history-of-all-packages/>
Cheers,
simon
^ permalink raw reply [flat|nested] 6+ messages in thread
* IDEA: Give Our Generations a Name
@ 2023-01-17 17:03 Nathan Dehnel
0 siblings, 0 replies; 6+ messages in thread
From: Nathan Dehnel @ 2023-01-17 17:03 UTC (permalink / raw)
To: jgart, guix-devel
I like it.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-01-19 11:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-16 23:40 IDEA: Give Our Generations a Name jgart
2023-01-17 1:52 ` Csepp
2023-01-18 18:31 ` Liliana Marie Prikler
2023-01-19 11:23 ` Csepp
2023-01-17 8:39 ` Simon Tournier
-- strict thread matches above, loose matches on Subject: below --
2023-01-17 17:03 Nathan Dehnel
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.