91–100 of 126 posts
Earlier quoted context omitted.
Come back when they have done this for 24000 third-party packages.
I don't see the connection. I didn't say that they have more packages, just that they have very good packaging tooling that makes it simple to make consistent packages.
Thanks Riku, debian has become an excellent distro thanks to the hard work of people like you. At the same time, it is sad to see how much work you guys need to do for things that should have been automated or done by the original developers... Let's hope AppImage changes that Edit: Changed flatpak to appimage
There's another standard? Why couldn't the deb guys just support Flatpak... damnit
A couple of weeks before they got accepted? Wow! I considered become a DD about 10 years ago, but a friend was going through the process and it took them over a year with at least one restart-from-scratch because the bureaucracy had been lost or something. > Regis NM did start somewhere in 2003. There was a period of him being on hold, in 2006 we did continue the process, which used some time, but most of the delay u…
I went through a similar experience with the NM process some ten years ago except I ended up giving up on the whole thing. After being told I absolutely had to answer a load of questions within a week for a week that happened to be very inconvenient, my answers then got completely ignored. I carried on maintaining the one package until a few years ago when I gave up because nobody would sponsor an upload until the fr…
Earlier quoted context omitted.
The problem is, my experience is "use autotools" and "don't package third party dependencies" make my software much harder for my users to build, and distributions are going to generally have out of date versions. I'm not saying packaging is easy, and I do try to make it friendly for distributions, but don't pretend that doesn't make it worse for general users in the process.
You don't have to use autotools, but it makes doing the right thing easy. If you want to use CMake (I much prefer it myself!) just make sure you use pkg-config, same with scons or whatever. These are all included in Fedora's (my distro of choice) package collection and there's no trouble using them to build. But please, if you decide to bundle third party libraries make sure you can build without them and use ones pr…
Earlier quoted context omitted.
I don't think having developers doing the packaging is an ideal situation. I often hear developers complaining about the multitude of GNU/Linux distros because they think it's somehow their responsibility to provide binaries. It's not. The role of the upstream developer is to make their build system easy to use so that other people (like distro maintainers, but also just "regular" users) can compile from source witho…
> - Don't bundle third-party dependencies. For security (and for better documentation of the true dependency graph) distros often must go through extra trouble to unbundle third-party libraries when present. Some project even add their own custom patches to their bundled source. Resist the urge to do this. If any of the dependencies aren't currently packaged in Debian, how would one follow this guideline?
Earlier quoted context omitted.
As a Fedora user the same problem used to exist for Perl packages some packages you could install via yum and some you'd have to get from CPAN. It's been probably a decade since I did anything serious in Perl so not sure if issue still exists but I suspect it still does because I have seen the same issue with python packages and the "PIP" tool. I see more and more programming languages trying to bundle their own depe…
CPAN packages can be translated into perl packages automatically in many cases, or with little modifications. Same for python, ruby and node packages. See fpm[1] for example of one of such tools. [1]: https://www.digitalocean.com/community/tutorials/how-to-use-...
Earlier quoted context omitted.
I went into systemd with an open mind, hoping the changes would be worthwhile to learn. I've come out the other end looking for alternatives... In the meantime I'll stick to an OS that uses init, and hope systemd get's better given enough time.
As someone who basically started getting into Linux with Systemd (I had dabbled before, but not in-depth) I love it. Mind expanding on what you don't like about it? One thing I do remember before Systemd though was the fact that every service was essentially a glorified bash script, and I hated that. With Systemd, there seems to generally be a much more clear-cut definition of how things operate, without all the cruf…
My biggest issue with systemd is that when something goes wrong, it's pretty impossible to tell why. As an example, virtually every system I've used with systemd after a few months starts to have different services fail to stop on shutdown, causing a timeout of (by default) one-and-a-half minutes. From searches that I've done online, I don't seem to be the only person who runs into this, but I haven't found any good solution, leaving me with the options to reduce the timeout to something more manageable, force shutdown my laptop literally every time I'm done using it, or sit through 90 seconds of systemd trying and failing to stop whichever service is failing that time. Maybe I'm just lucky, but it's fairly rare that any of my non-systemd systems is unable to shut down properly once, let alone every single time consistently.
Earlier quoted context omitted.
I watched the Rust packaging effort via the mailing list, and that seems to be going quite well. Would you happen to know a good video or writeup on why language-specific package managers are a bad idea? I mean, the situation with C and C++ libraries seems significantly worse to me, and I personally really enjoy having the fully Crates.io index at my disposal on any box that runs Cargo.
Not your parent, but I personally believe that using "package managers" to describe both of these things conflates the issue. That is, both are valuable, for different reasons. The shortest way that I can describe it is this: I use my system package manager to install things for software that I'm not developing, but language-specific managers for software that I am actively developing. When I used to write a lot of R…
I think language-specific package managers are fine for easily sharing source code amongst developers using the same language, but they shouldn't be used in a production system.
Earlier quoted context omitted.
As a Fedora user the same problem used to exist for Perl packages some packages you could install via yum and some you'd have to get from CPAN. It's been probably a decade since I did anything serious in Perl so not sure if issue still exists but I suspect it still does because I have seen the same issue with python packages and the "PIP" tool. I see more and more programming languages trying to bundle their own depe…
CPAN packages can be translated into perl packages automatically in many cases, or with little modifications. Same for python, ruby and node packages. See fpm[1] for example of one of such tools. [1]: https://www.digitalocean.com/community/tutorials/how-to-use-...
Earlier quoted context omitted.
Not your parent, but I personally believe that using "package managers" to describe both of these things conflates the issue. That is, both are valuable, for different reasons. The shortest way that I can describe it is this: I use my system package manager to install things for software that I'm not developing, but language-specific managers for software that I am actively developing. When I used to write a lot of R…
There's no need for two styles of package managers. GNU Guix and Nix can serve both purposes (and more) very well, for example. I think language-specific package managers are fine for easily sharing source code amongst developers using the same language, but they shouldn't be used in a production system.
Nix and Guix don't work on Windows, right? They're still not close to a solution until they do.