IRC channel logs


back to list of logs

<gnu_srs>youpi: The latest problem occurring with Hurd packages now is dbus (in addition to hurd itself and init-system-helpers) requiring usrmerge/usr-is-merged.
<gnu_srs>Can we create +hurd package removing dependencies on these packages, i.e. no /usr aliasing. WDYT?
<gnu_srs>I'm discussing with Devuan people now to establish a Devuan GNU/Hurd port.
<gnu_srs>If we could revert the Debian changes and publish in unreleased that would not be needed!
<youpi>I don't think it's worth pursing such a divergence from debian
<youpi>we've been there already with the converse: /usr being a symlink to /
<youpi>that brings headaches all around
<gnu_srs>I know about the failed GNU/Hurd effore to symlink /usr to /.
<gnu_srs>Nevertheless, Guix don't suffer the merged /usr problems, so why not try (outside Debian if necessary)?
<youpi>because that doesn't bring any technical benefit?
<gnu_srs>Debian is not the whole Universe
<youpi>you're making the story upside down... Debian was the last one still not using merged /usr
<gnu_srs>Many people don't wan merged /usr. Why should they be forced onto it??
<youpi>and Debian using merged-usr doesn't prevent other distributions from doing things otherwise
<youpi>we're not changing the hurd source in any way, for instance
<youpi>you're twisting the things
<gnu_srs>I thought GNU/whatever is about choice, not force like M$or Apple"
<youpi>? no, GNU is not about choice
<youpi>it's about free software
<youpi>and debian choosing merged-usr does *not* mean other distributions can't do otherwise
<youpi>but we'd better make debian gnu/hurd align on debian gnu/linux
<youpi>otherwise it's useless headaches
<youpi>we already have enough of them
<gnu_srs>and if people want something else they should not be hindered to make changes, right!
<youpi>without adding some
<youpi>yes, sure
<youpi>and if you really properly look at things, they won't need changes in the debian/ bits
<youpi>again: we're not changing the upstream source habits
<youpi>that would make upstream software uninstallable on non-merged-usr
<gnu_srs>The problem is not upstream it is Debian!
<youpi>how can debian be a problem for other distributions?
<gnu_srs>Debis forcing merged /usr on their users (including Hurd)!
<youpi>then users can switch to another distribution
<gnu_srs>OK, so changing Hurd packages adding +hurd is no way forward?
<gnu_srs>I proposed to e.g. remove the usr-is-merged dependency for dbus and create a +hurd version, 1.14.10-3+hurd1 like Devuan does.
<gnu_srs>And publish in unreleased.
<youpi>gnu_srs: why publishing it in debian unreleased?
<youpi>devuan can have its own unreleased
<youpi>I don't plan to spend time on having a non-merged-usr alternative in Debian GNU/Hurd
<youpi>and thus I don't plan to spend time on uploading patched packages (which would have to be re-done for each new version!) to debian unreleased just for non-merged-usr support
<gnu_srs>Your opinion is perfectly clear, thanks!
<gnu_srs>Nevertheless Guix does not suffer from merged /usr problems, right?
<youpi>so what
<youpi>Debian GNU/Hurd doesn't suffer more from merged /usr than Debian GNU/Linux does
<youpi>so we don't need to care
<gnu_srs>Ok, I'll try to convince Devuan people to help out here.
<youpi>Debian GNU/Linux will handle it
<gnu_srs>Devuan GNU/Linux does not suffer from the merged /usr problems either, like Guix.
<youpi>so what
<gnu_srs>And I'll convert and upgrade all my hardware boxes to Devuan to avoid the Debian mess.
<gnu_srs>It is very unfortunate that you are a Debian fan, more than an upstream person :(
<youpi>I'm not a debian
<youpi>I'm not an upstream person either
<youpi>I just manage where I think my time will be best spent
<youpi>people decided to go on merged-usr
<youpi>fine for them
<youpi>they'll handle the issues
<youpi>personally, I haven't seen any on my boxes
<youpi>so apparently I don't need to care
<youpi>thus not caring
<youpi>really, the merged/non-merged-usr is bikesheding at some point
<youpi>we have more important things to work on