Hello Samuel, Thanks for the clarification, yes I understand duplication is not great.
But the use case here is someone wants to develop/test now from the latest and greatest version, the bleeding edge where the development actually happens. For testing/working on unreleased features like that, there is no replacement for a raw git clone and make. Plus, there are people who are devs and understand git and make but are not from a Debian background. It feels much more natural to them to have a build script that fetches fresh upstream code instead of trying to navigate backporting patches into source packages. People do find it useful based on the emails I have, but if it doesn't fit the wiki's focus, that is completely fine. I will just drop the patch and host it in a standalone repo for those who need it. Regards, Milos On Mon, Mar 23, 2026 at 3:08 PM Samuel Thibault <[email protected]> wrote: > > Hello, > > Milos Nikic, le lun. 23 mars 2026 10:05:11 -0700, a ecrit: > > The script is tested on both 64 and 32 bit and it looks useful to people. > > I'm not sure in which way it is useful, actually. > > Sure, it allows to build mig/gnumach/hurd, but then what? > > If people want to change one of these, they have to rebuild it, and know > to install it, etc. and we already have building packages for > mig/gnumach/hurd, if something is missing there, it should be documented > there, duplicating the information would lead to two half-up-to-date > copies rather than one up-to-date. > > > +# Persist PATH update > > +if ! grep -q "$GNU_PREFIX/bin" ~/.bashrc; then > > + echo "export PATH=\"$GNU_PREFIX/bin:\$PATH\"" >> ~/.bashrc > > +fi > > +export PATH="$GNU_PREFIX/bin:$PATH" > > I don't think it's good to modify people's .bashrc under their feet, > they should really know what they are doing. > > Samuel
