5 ms·
I have never hung my OS X boot simply by updating Homebrew packages. I have frequently hung up my Linux distro boot simply by apt-get updating. To the point th
by lectrick 12y ago
I have never hung my OS X boot simply by updating Homebrew packages.
I have frequently hung up my Linux distro boot simply by apt-get updating. To the point that I now run all my Linux OS'es in a VM and take a snapshot prior to updating. Coming from a Mac background, this possibility is not only ridiculous, it's fucking unacceptable. And it happens BECAUSE apt-get and yum mutate the OS install instead of installing into userland the way Homebrew does.
Game, set, match.
- stephenr 12y agoif something is stopping your OS from booting, it is part of the OS, and thus must be installed as part of the OS, and not as a user land tool.
- dragonwriter 12y agoSure, but having a separate package manager (or, at least, a distinct package management "realm") for pure userland things that cannot break the OS install so that you know when you install from it you will not break the install, even with dependencies that may get pulled in, is good for piece of mind. It might be better to have a single package manager which supported bother user and OS packages, and clearly distinguished between them, but in the absence of that it is good to have a way to install what you intend to be user packages with an assurance that they won't be installing OS-level things that might break the OS install. Even aside from this guarantee, its good to be able to install things for a user, but to have other users on the same machine whose environments are unaffected by the install.
- cozzyd 12y agoAs I mentioned in a different comment, I don't think there's anything about yum/rpm that precludes doing this. Provided someone took the time to create a repository of relocatable rpm's, you could create a "yumbrew" script that does something like yum-downloader --deps --destdir=~/.myrpms foo-1.3.3.7; rpm -U --prefix=~/.yumbrew/ --dbpath=~/.yumbrewdb ~/.myrpms/* or whatever version of that would actually work. This has the added advantage that you don't have to compile the packages (although if you wanted to, you could make the script do that too..)
- stephenr 12y agoDpkg already has a "--root" option to use a different path for both installing packages and storing the dpkg info. I think the biggest issue would be having it recognise packages already installed in the system when it's using a different info directory - it's possible a lot of packages would get re-installed "locally". Other than that, I believe your concept should work on Debian.
- cheald 12y agoIt rather sounds like your preference for brew is that brew is a user-level tool that can't update system packages. There's certainly a case to be made user-scoped package managers are valuable, but "my package manager is capable of updating everything including my kernel" is a feature, not a bug, IMO - brew's constant conflicts with OS X's Apple-provided toolchains should be more than sufficient evidence as to why. apt-get et al are extremely capable package managers, and in my experience result in much more stable and consistent installs than brew does, specifically because it can be aware of things like OS-level dependencies which it can then manage.
- rb12345 12y agoThis does make me wonder what is so special or unusual about your various Debian installs. Outside of attempting a woody->sid dist-upgrade in the distant past, I have never had problems with "apt-get [dist-]upgrade" breaking anything to the point of not booting, and certainly not a simple "apt-get update" to refresh the package list. (This is using both Ubuntu and Debian stable.)