231–238 of 238 posts
Earlier quoted context omitted.
Try macports for a BSD style packaging for the mac.
What's the advantage of using macports over Homebrew?
Earlier quoted context omitted.
No, but they're representative of the decision process. "Should we do A or B" results in people popping up supporting A, B, C, D, and E, and the decision tends to be "let's support them all". And as the original article we're commenting on discusses, that "support" comes in the form of "hey package maintainers, here's what you have to deal with".
This is a misunderstanding of how Debian works.
I love using Debian, I care deeply about Debian Policy and Debian's procedures, I enjoy many aspects of the Debian community, and I'm also well aware of where Debian has difficulties.
Earlier quoted context omitted.
What's the advantage of using macports over Homebrew?
For one, it works just fine on multi-user Macs as it installs software under the uid/gid of the user who installed Homebrew somewhere under /usr/local whereas Homebrew installs it the proper way as root:admin and doesn't create a shitload of permission problems.
I have a lot of trouble with Homebrew on multiuser Mac systems. Running `brew install ...` or `brew update` as anyone but the user who originally installed Homebrew almost always fails because of permission errors (or it successfully installs, but then causes permission errors in the future for the user who installed Homebrew). Whenever I need to use Homebrew commands now, I use `sudo -iu otheruser` to switch to the user account who first installed Homebrew in order to avoid the permissions issues. I'm really baffled that Homebrew doesn't support the multiuser system case. Is it so rare to share a system nowadays? I've had this issue on multiple Macs and fresh installs, so I don't think this is some fluke bug.
Earlier quoted context omitted.
My first upload will soon be 10 years ago. One thing that is definitely noticeable is that while creating a package is still by no means trivial, it has definitely become much, much easier. 10 years ago, you had a handful of very idiosyncratic build helpers to help you manage your package. Today, effectively it's just one [1], debhelper, and it has become trivial to build packages with it. It's a very powerful framew…
The Debian tooling can be really fantastic at time. If the upstream is clean (project with a proper setup.py/Makefile/CMake/Makefile.pl/etc), you only have to declare the meta-data, the build and runtime dependencies and you are set. But at the same time, I'm not a big fan of other aspects. For example, the fact the packaging is split between at least 3 or 4 files and generally something close to a dozen (at least co…
Is there something else missing?
I've been using Debian / Ubuntu for many years, as much due to inertia and familiarity as anything else. And I have a lot of respect for the project. If I wanted to start being a contributor to a distribution, which one would be the best to dive in to?
We also have a cool website that helps you figure out what you want to do and how to apply it: https://whatcanidoforfedora.org/
(Yes, it's inspired by the Mozilla one!)
Earlier quoted context omitted.
The Debian tooling can be really fantastic at time. If the upstream is clean (project with a proper setup.py/Makefile/CMake/Makefile.pl/etc), you only have to declare the meta-data, the build and runtime dependencies and you are set. But at the same time, I'm not a big fan of other aspects. For example, the fact the packaging is split between at least 3 or 4 files and generally something close to a dozen (at least co…
I'm curious, in what way do you feel it's less advanced? Mock supports leveraging qemu-user-static for doing foreign architectures as of Mock 1.4.11, which I think was the only major feature that the Debian tools had for a while that Mock lacked. Is there something else missing?
Also, cowbuilder runs fine with several instance running at the same time, mock is a bit more sketchy in that regard. Basically, you can only build one package at a time. Typically, it's a bit of an issue for my personal scripts: https://github.com/kakwa/amkecpak, in them I can basically do make rpm -j 42 to build 42 packages at the same time, but with mock/mockchain, the chroot creation has some concurrency issues.
In fairness, I used the rather old mock version packaged by Debian, I've not looked at 1.4, it seems that some of these issues are addressed now.
I used debian for over 10 years and never managed to contribute anything. 10 Minutes after using homebrew for the first time I sent in a PR to update a package to the latest version and update the built dependencies.
> 10 Minutes after using homebrew for the first time I sent in a PR to update a package to the latest version and update the built dependencies. And that's exactly why I use and trust Debian.
> And that's exactly why I use and trust Debian.
Comments like this are why you are an asshole, mr throwaway30012.
I have a naive question (I'm a long time Debian user, but never really tried to contribute): why isn't all the Debian in a single git repository? I'm not suggesting to vendor all the third party code but only all the packaging information, like, say, libreelec does (and I assume many others)