Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian upgrade as source for 3-way merge #2869

Open
Chemin1 opened this issue Aug 10, 2019 · 3 comments

Comments

@Chemin1
Copy link
Contributor

commented Aug 10, 2019

@markus2330 Thursday we discussed about using a version controlled /etc to do the statistical part for the 3-way merge. Thinking about this I made a similar plan which I hope includes a selection of packages and thus config files that is representative (still have to check how much this really is) and reproducible.

  • Install Debian 9 into a virtual machine
  • Extracting /etc (and potentially other relevant places)
  • Upgrading to Debian 10
  • Extracting /etc
  • Comparing the two versions of /etc

This way we'd avoid having to install Elektra into the VM for example and could use the exact same version from the "outside" instead. I have spent some hours with the virtualization and mounting stuff so far.

At the moment I'm having some problems. Before investing a lot of time into solving them I wanted to clarify if this seems like a reasonable approach to you. One question that is still open is that those are only 2 versions and we would actually like to look at 3.

@Chemin1 Chemin1 self-assigned this Aug 10, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

and potentially other relevant places

You can safely reduce to config files in /etc.

This way we'd avoid having to install Elektra into the VM for example and could use the exact same version from the "outside" instead.

From the perspective of Elektra's goals, the design of a case study where Elektra is actually used to upgrade all files in a system is much more interesting. (Compared to a system where Elektra is not used.) Maybe you can realize this at least for LCDproc.

Note that we have several docker images (scripts/docker) and it should be easy to install Elektra there.

One question that is still open is that those are only 2 versions and we would actually like to look at 3.

To get the third, you need to make permutations in the config files:

  1. ours: is the config file from Debian 9 with our changes
  2. theirs: is the config file in the package of Debian 10
  3. origin: is the unmodified config file of Debian 9

The ucf tool already provides these 3 files for you but then you need to patch the packages to use 3-way merge which might (depending on your Debian skills) too time-consuming for you. For LCDproc it might be reasonable, though.

For the statistics, you can "simulate" the upgrade, by extracting the files, running Elektra merges outside of the container, and count the prevented merge conflicts.

For the "permutations" of the config files, it would be best if you can collect real config files of LCDproc by asking people to submit their config files either in a repo or to send them to you by email. Can you prepare a repo (with a README.md) and a message to be send to the LCDproc mailing list?

As already said, I can also send you config files with merge conflicts. I'll do the buster upgrades on my machines soon.

@Chemin1

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2019

The ucf tool already provides these 3 files for you but then you need to patch the packages to use 3-way merge which might (depending on your Debian skills) too time-consuming for you. For LCDproc it might be reasonable, though.

You mean similar to this https://www.libelektra.org/tutorials/merge-configuration-files but with LCDproc instead of samba?

Note that we have several docker images (scripts/docker) and it should be easy to install Elektra there.

As we have talked about virtual machines for the statistic: Does this mean that Docker images are good enough for the statistical part as well? I've just built one for the first time and still have to see how this all works exactly.

From the perspective of Elektra's goals, the design of a case study where Elektra is actually used to upgrade all files in a system is much more interesting.

So this would be an additional goal for my thesis? We apparently had a similar idea for the statistical part

For the statistics, you can "simulate" the upgrade, by extracting the files, running Elektra merges outside of the container, and count the prevented merge conflicts.

and I did not think about more so far because this looked like the relevant part for my research question.

Can you prepare a repo (with a README.md) and a message to be send to the LCDproc mailing list?

Both done. https://github.com/Chemin1/config-files

As already said, I can also send you config files with merge conflicts. I'll do the buster upgrades on my machines soon.

I'd really appreciate that. We could handle this with the new repository too.

@Chemin1 Chemin1 added this to To do in Improve 3-way merge via automation Aug 11, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

You mean similar to this https://www.libelektra.org/tutorials/merge-configuration-files but with LCDproc instead of samba?

Yes, similar. LCDproc does not use ucf, so it would need a standalone script. As starter, you could also reproduce if that what is described in that tutorial actual works.

As we have talked about virtual machines for the statistic: Does this mean that Docker images are good enough for the statistical part as well? I've just built one for the first time and still have to see how this all works exactly.

Of course docker is also fine.

So this would be an additional goal for my thesis? We apparently had a similar idea for the statistical part

It is actual not a new goal but two sides of the same coin:

  1. case study with LCDproc to show that you reach your goal practically
  2. generalize with different config files: show that you reached your goal not just for LCDproc

In gernal, to have a case study is always a big plus for a thesis. The case study, however, can be limited to LCDproc. For the statistics it would be good to also have other config files (and not only LCDproc).

and I did not think about more so far because this looked like the relevant part for my research question.

It does not show that what you have done is practically usable.

Both done. https://github.com/Chemin1/config-files

Thank you, I added some comments. Then please create https://github.com/ElektraInitiative/lcdproc-config-files with the content. And write that PRs are needed.

I'd really appreciate that. We could handle this with the new repository too.

Then you should give some basic structure so that it is clear where to add the files. So that your evaluation is sound, you should separate LCDproc config files that were modified based on a Stretch config file and LCDproc config files that origin from other sources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.