search

grml / grml-debootstrap

wrapper around debootstrap
59 stars 27 forks source link

add `Depends:` `dosfstools` #227

Closed adrelanos closed 1 year ago

adrelanos commented 1 year ago

since required for builds with --vmefi

fixes https://github.com/grml/grml-debootstrap/issues/225

mika commented 1 year ago

nitpick: please run wrap-and-sort -tas (from devscripts) to ensure the lines are sorted properly, this makes reviewing/tracking down changes way easier :)

Also I don't think it's only "since required for builds with --vmefi", but for every EFI related use case (so also--efi ...`), so maybe use something like that for the commit message:

debian: add dosfstools to Depends for EFI use case

It's required for builds with `--vmefi` and `--efi`, since those depend on mkfs.fat.
Closes: https://github.com/grml/grml-debootstrap/issues/225

(If you'd prefer me to take care myself, let me know)

adrelanos commented 1 year ago

nitpick: please run wrap-and-sort -tas (from devscripts) to ensure the lines are sorted properly, this makes reviewing/tracking down changes way easier :)

Done.

Ah, nice. I never stumbled over that tool. I thought we group together the dependencies based on criteria such as "what is similar". dosfstools, e2fsprogs are similar but less related to fdisk.

Also I don't think it's only "since required for builds with --vmefi", but for every EFI related use case (so also--efi ...`), so maybe use something like that for the commit message:

debian: add dosfstools to Depends for EFI use case

It's required for builds with `--vmefi` and `--efi`, since those depend on mkfs.fat.
Closes: https://github.com/grml/grml-debootstrap/issues/225

Also done.

(If you'd prefer me to take care myself, let me know)

I actually would generally prefer if that's okay on your side too. I can do some more or less code heavy lifting but I am not so good with great commit messages, what to split, what to squash, rebase, git wizardry etc. If something is merged sooner, then chances are higher the next thing that follows are more code improvements. Otherwise it's delayed per perfections of the current pull request.

For example once https://github.com/grml/grml-debootstrap/pull/230 is merged, I am eagerly awaiting to work on perfecting the other error handling code. But I feel I cannot really work on it prior the merge because I wouldn't know if what I produced makes sense, I might have missed something. By rushing ahead I might run into a merge conflict that I myself produced which are cumbersome, time consuming to fix for me, perhaps because I lack the trick on how do that.

mika commented 1 year ago

nitpick: please run wrap-and-sort -tas (from devscripts) to ensure the lines are sorted properly, this makes reviewing/tracking down changes way easier :)

Done.

Great, thanks! Merged :)

Ah, nice. I never stumbled over that tool. I thought we group together the dependencies based on criteria such as "what is similar". dosfstools, e2fsprogs are similar but less related to fdisk.

Also I don't think it's only "since required for builds with --vmefi", but for every EFI related use case (so also--efi ...`), so maybe use something like that for the commit message:

debian: add dosfstools to Depends for EFI use case

It's required for builds with `--vmefi` and `--efi`, since those depend on mkfs.fat.
Closes: https://github.com/grml/grml-debootstrap/issues/225

Also done.

Thanks!

(If you'd prefer me to take care myself, let me know)

I actually would generally prefer if that's okay on your side too. I can do some more or less code heavy lifting but I am not so good with great commit messages, what to split, what to squash, rebase, git wizardry etc. If something is merged sooner, then chances are higher the next thing that follows are more code improvements. Otherwise it's delayed per perfections of the current pull request.

Ah sure, no problem then

For example once #230 is merged, I am eagerly awaiting to work on perfecting the other error handling code. But I feel I cannot really work on it prior the merge because I wouldn't know if what I produced makes sense, I might have missed something. By rushing ahead I might run into a merge conflict that I myself produced which are cumbersome, time consuming to fix for me, perhaps because I lack the trick on how do that.

No worries, it's fine for me to take care, but I also like to share tricks, so let's try to find a proper balance for both of us! :)

Merged, thx! :+1:

adrelanos commented 1 year ago

Appreciated! :)