Hi Shengjing, Raju and Go Packaging Team,
As I read you (Raju and Shengjing) discussed about a code duplicate, I
wrote some notes of my doubt on packaging. I'm afraid I haven't found
any discussions or documents about packaging the forked repo yet, but
maybe already discussed before?
I am a newcomer in Debian packaging, and I still have a problem with
handling the forked repo. Here is my note, would you please review and
correct for me? There is also some questions below.
Go uses remote repo location as the package import path, which will cause
some problems during the Debian packaging if the import path is "forked"
repo location.
I've sorted out the methods for solution in three ways:
[A] Method A: Package the base repo, put the import path of the forked
repos into `XS-Go-Import-Path` in `d/control`, and patch all codes
that use the forked repo to be compatible with the base repo.
[B] Method B: Package the base repo, and make all codes to use the base
repo. The difference with [A] is, [B] does not use
`XS-Go-Import-Path`.
[C] Method C: Package both the base repo and the forked repo.
When patching with [A] or [B], the code duplicate does not occur.
However, if a lot of programs uses the forked repo, we'll need to patch
all of them. When patching with [C], the forked repo shares many of the
codes with the base repo, which inevitably results in code duplicate.
Let's take an example. Here are two repos that don't make much difference.
[1] Base repo: github.com/nsf/termbox-go (already packaged - golang-github-nsf-termbox-go)
[2] Forked repo: github.com/jesseduffield/termbox-go (not yet packaged)
[2] is the fork of [1], only one commit has been made, and the change is
trivial. In my opinion, [A] or [B] would be appropriate in this case.
Here's another example. These two repos are significantly different from
each other.
[3] Base repo: github.com/jroimartin/gocui (already packaged - golang-github-jroimartin-gocui)
[4] Forked repo: github.com/jesseduffield/gocui (not yet packaged)
[4] is the fork of [3], and many commits have been made. Many files are
different. In my opinion, [C] would be appropriate in this case.
Here are my questions:
1. With the first example in the note[1,2], which one is the preferred
way for the team? [A] or [B]? Or another way?
2. [5] does not allow data copies. With the second example[3,4], much or
less, the forked repo shares the code with the base repo. Can we use
[C] for handling?
[5] https://www.debian.org/doc/debian-policy/ch-source.html#convenience-copies-of-code
3. If 2. is not allowed, what is the preferred way for the team?
4. If 2. is allowed, is there a criterion for judging first example and
second example? The code difference rate?
Please review and correct my note for my future packaging work.
Thank you for reading this broken English.
Thank you!
--
Jongmin Kim
OpenPGP key located at https://jongmin.dev/pgp
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE 9472 D39D 8D29 BAF3 6DF8
Attachment:
signature.asc
Description: PGP signature