<div dir="auto">Sigh.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">2023年1月7日(土) 21:04 Owen Thomas <<a href="mailto:owen.paul.thomas@gmail.com" rel="noreferrer noreferrer" target="_blank">owen.paul.thomas@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 7 Jan 2023 at 22:46, Colin Law <<a href="mailto:clanlaw@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">clanlaw@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 7 Jan 2023 at 10:37, Owen Thomas <<a href="mailto:owen.paul.thomas@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">owen.paul.thomas@gmail.com</a>> wrote:<br>
><br>
> Just produce a distribution that has a single package manager<br>
...<br>
<br>
Isn't this exactly what Ubuntu is aiming for with snaps?<br></blockquote><div><br></div><div>IDK, but if that is so, then am I correct in thinking that every other package manager can be removed and in8stalled as a snap if the user wants something else?</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Not sure whether I should bring the elephant in the room up at this point, but ...</div><div dir="auto"><br></div><div dir="auto">Or which elephant.</div><div dir="auto"><br></div><div dir="auto">Okay, let's keep things light.</div><div dir="auto"><br></div><div dir="auto">Dependency hell is the problem. Nobody has really solved the problems of assembling applications from disparate parts sourced from developers from opposite ends of multiple spectra of methodologies and architectural affinities. We have barely begun to solve the versioning problem, but aren't yet really very far along.</div><div dir="auto"><br></div><div dir="auto">Package managers were invented to solve both those problems, and a few other difficult problems, as well. Each was invented for a fairly cohesive group that shared methodologies and architectural affinities. That's why they don't mix all that well. Get a package manager out of context, and it doesn't work very well. If you use the current descendants of RPM on Debian, you have to surround it with a separate library tree. Not impossible, but tricky.</div><div dir="auto"><br></div><div dir="auto">Terabyte disks for cheap makes such things more feasible. </div><div dir="auto"><br></div><div dir="auto">Snaps were an extension of the idea of separate library trees – give every application its own library tree – which is great, except that it isn't. Getting every snap to be able to keep itself up to date is just one of the easier problems that shows up.</div><div dir="auto"><br></div><div dir="auto">Mac OS is essentially a single cohesive dev group. If you start loading FOSS software that didn't get developed within that group, or doesn't have a maintenance team within that group, and you end up installing one or more of something like nine 3rd party package managers. And they can end up fighting with each other. </div><div dir="auto"><br></div><div dir="auto">Likewise MSWindows. If you want FOSS there, you will install Cygwin or MinGW or something like that.</div><div dir="auto"><br></div><div dir="auto">It's the nature of the beast, until we as an industry can figure out for real what software engineering entails. </div><div dir="auto"><br></div><div dir="auto">And that gets into stuff that is tantamount to religion. (For good reason. Software is abstract.)</div><div dir="auto"><br></div><div dir="auto">I could solve the problem – with a budget in the range of millions of dollars, but it would add yet another solution incompatible with the rest.</div></div>