No description
Find a file
Thomas Lamprecht 30cbcf171c docs, buildsys: expand on how to pull updates
drop the makefile one, subtree fetch is outdated and it's better to
just pull manually directly

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
2022-10-06 01:14:00 +02:00
src bump version to 0.8.36+pve2 2022-10-06 01:06:02 +02:00
debian buildsys: link top-level debian to subtree tracked one for buildsys 2022-10-05 21:54:24 +02:00
Makefile docs, buildsys: expand on how to pull updates 2022-10-06 01:14:00 +02:00
README docs, buildsys: expand on how to pull updates 2022-10-06 01:14:00 +02:00

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Why Rebuild

To avoid common pitfalls between switching to ifupdown2, like, for example, the removal of the
networking units link, effectively disabling it.o

# How is the Source Tracked

We're using git's subtree functionality, which is basically just a convenience wrapper around the
age old subtree merge strategy.

The initial addition was done with the following command:
```
git subtree add -P src --squash https://salsa.debian.org/debian/ifupdown.git 0.8.36
```

## Subtree Rules

* We squash update commits to avoid making the git log explode here, one can always checkout the
  upstream repo for details.

* We try to keep change in the subtree copy contained to packaging as much as possible, anything
  else should be upstreamed first, and only applied locally afterwards.

* We're fine with merges, as they're required anyway. Especially d/changelog and the pre/post
  scripts will need to be adapted. Checkout upstream changes closely and ensure that our main goal
  (switching from ifupdown to ifupdown2 seamlessly) can still be achieved.

# Separate Subtree Changes from Parent

Quoting a tip from `man git-subtree`:

> In order to keep your commit messages clean, we recommend that people split their
> commits between the subtrees and the main project as much as possible. That is, if you
> make a change that affects both the library and the main application, commit it in two
> pieces. That way, when you split the library commits out later, their descriptions
> will still make sense. But if this isn't important to you, its not necessary. git
> subtree will simply leave out the non-library-related parts of the commit when it
> splits it out into the subproject later.

## Pull in New Version

Use something like the followign command (adapt the refspec at the end) to pull
and merge in a new upstream revision:

```
git subtree pull -P src --squash https://salsa.debian.org/debian/ifupdown.git 0.8.X
```

Handle merge conflicts and ensure that the *build* post/pre rm scripts don't do anything that would
interfere with switching to ifupdown2 or purging this package later.