On Fri, May 21, 2021 at 09:07:10AM +0800, zhangjialing wrote: > Hi, I have known upstreaming first , I will make a plan for this debian port > .
Good. > Please, when we upstreaming our patch , Is there a version limit for the > soft like gcc ,glibc I honestly fail to understand what this is supposed to mean. When upstreaming you'll always work with the respective development branch of the relevant upstream project. If you post patches for an older version, the likely outcome is that you'll be asked to post rebased versions. > when the upstream work done , what is the next. This is less of a specific point in time than you may think. From your side, upstreaming is (mostly) done when your changes have been merged into the upstream VCS. A little later the respective upstream produces a release. Yet later, Debian includes that release. Often times (and for gcc and glibc in particular), new upstream releases hit the experimental suite first and only later go to unstable. What I am trying to convey here is that there is a significant amount of delay between you upstreaming your work and it being available in Debian. I think most ports in Debian were cross bootstrapped from another port. What this means is that you build cross toolchains from Debian sources and then cross build the packages required for installing build-essential. It is a tedious process requiring more than 150 builds. For earlier ports this has been manual and it is now being automated in https://wiki.debian.org/HelmutGrohne/rebootstrap. Recent ports have forked this tool to add their port-specific fixes and performed the initial bootstrap using it. Once rebootstrap finishes, a few packages (e.g. perl) are left to be manually cross built. Once you have build-essential, you continue bootstrapping natively. Please contact me once a version of binutils that supports loongarch64 is included in any Debian suite. This is the point where I can help you adapt rebootstrap. Helmut