4 ms·

I have to admit, I am lazy and tend to use the Debian packaged software with apt-get, etc. The only drawback is the some packages seem to be quite a bit behind

I have to admit, I am lazy and tend to use the Debian packaged software with apt-get, etc. The only drawback is the some packages seem to be quite a bit behind the up to date versions on the project's git repository. Personally I tend to choose the convenience of the Debian packaged software to wrangling with fiddly dependencies during compilation.

knocte 7y ago
I think we need the best of both worlds: debian packagers (and packagers from other distros) working on flatpaks and snaps instead of deb/rpms, so that the work can be reused across distributions. Many devs of upstream software refuse anyway to start using these new package systems, so there's an opportunity here.
- kick 7y ago
  The article implies that's sort of the worst of all possible worlds here, and I have to agree.
  - knocte 7y ago
    I'm sorry but, I can't believe we're already on the 20s, and still one has to hear(read) opinions like this. Seems like some members of the opensource community will never learn the lessons from the past. And I'm not talking exactly about all the duplicated effort that packagers use(d) to perform in order to distribute software for each distribution. I'm especially referring to the gatekeeper mentality of curating/releasing software. Letting developers distribute their own software is not negative per-se. Can negative things happen out of this? Right, of course, whenever you give someone more power, there are more chances that it can be corrupted. But: a) Thanks to the sandboxing technologies used in the Linux packaging solution of this century (e.g. flatpak, snap), one doesn't need to worry so much about how evil a developer is. b) If a software project is truly opensource, there's no reason why the packaging efforts on top of it cannot be opensourced either. What does this mean? That its packaging approach can be forked in the same way as one would do with the sources of the project itself. One could even fork the packaging of a project, not just because it contradicts their principles (e.g. an app that requires too many OS permissions for what it's meant to achieve), but also because it doesn't provide good stability (e.g. an app which keeps sending updates marked as bugfixes when in reality it's bringing new features that introduce regressions). What my opinion boils down to is: - There shouldn't be any difference between downstream and upstream. If you think a developer is not packaging well their software, why not send him a PullRequest instead of to other group of developers (packagers) that didn't write the software originally? - Developers might suck at packaging, granted. But they also suck at UX/UI design, but end up doing the best thing they can. Ultimately a designer might join them to improve the project, why not letting also the helping hand of packagers contribute to upstream directly, instead of setting up their own cult?
    - kick 7y ago
      I'm sorry but, I can't believe we're already on the 20s, and still one has to hear(read) opinions like this. Seems like some members of the opensource community will never learn the lessons from the past. The lessons of the past are that all attempts to draw users away from their distribution's packages end in misery. AppImage is the only half-decent "solution" here, and not even it's very good. And I'm not talking exactly about all the duplicated effort that packagers use(d) to perform in order to distribute software for each distribution. I'm especially referring to the gatekeeper mentality of curating/releasing software. There is no duplicate effort from repackaging software for another distribution. You can literally automate most of it 90% of the time, and when you can't it only takes a minute to write. a) Thanks to the sandboxing technologies used in the Linux packaging solution of this century (e.g. flatpak, snap), one doesn't need to worry so much about how evil a developer is. Not even Apple gets sandboxing perfect, and Red Hat and Canonical demonstrate incompetence all the time. b) If a software project is truly opensource, there's no reason why the packaging efforts on top of it cannot be opensourced either. What does this mean? That its packaging approach can be forked in the same way as one would do with the sources of the project itself. This already happens with the current methods; what you're proposing is a terrible solution to a problem that doesn't exist. One could even fork the packaging of a project, not just because it contradicts their principles (e.g. an app that requires too many OS permissions for what it's meant to achieve), but also because it doesn't provide good stability (e.g. an app which keeps sending updates marked as bugfixes when in reality it's bringing new features that introduce regressions). This demonstrates that you probably aren't aware of how packaging actually works on Linux. Distributions like Debian and RHEL backport security and bugfixes while preventing feature releases. There shouldn't be any difference between downstream and upstream. If you think a developer is not packaging well their software, why not send him a PullRequest instead of to other group of developers (packagers) that didn't write the software originally? "Pull Request" is a GitHub-specific term, and GitHub is awful for packaging. Further, this completely misses the point of packagers. I'm just wondering, does your primary computer run Linux or Windows? Also, your claim "There shouldn't be any difference between downstream and upstream." directly conflicts with your claim on feature updates. Developers might suck at packaging, granted. But they also suck at UX/UI design, but end up doing the best thing they can. Ultimately a designer might join them to improve the project, why not letting also the helping hand of packagers contribute to upstream directly, instead of setting up their own cult? Packaging software is not a cult by literally any possible definition of "cult," literally or figuratively. No packager is going to waste their time contributing to something that actively makes the Linux ecosystem worse. With flatpak and snap, the size per program skyrockets, and the amount of hassle on the user skyrockets, similarly.
kick 7y ago
That's good, and exactly what Drew is recommending! Your distribution's packagers work terribly hard to make your experience good, and so you should absolutely make use of the fruit of their work!

knocte 7y ago

I think we need the best of both worlds: debian packagers (and packagers from other distros) working on flatpaks and snaps instead of deb/rpms, so that the work can be reused across distributions. Many devs of upstream software refuse anyway to start using these new package systems, so there's an opportunity here.

kick 7y ago
The article implies that's sort of the worst of all possible worlds here, and I have to agree.
- knocte 7y ago
  I'm sorry but, I can't believe we're already on the 20s, and still one has to hear(read) opinions like this. Seems like some members of the opensource community will never learn the lessons from the past. And I'm not talking exactly about all the duplicated effort that packagers use(d) to perform in order to distribute software for each distribution. I'm especially referring to the gatekeeper mentality of curating/releasing software. Letting developers distribute their own software is not negative per-se. Can negative things happen out of this? Right, of course, whenever you give someone more power, there are more chances that it can be corrupted. But: a) Thanks to the sandboxing technologies used in the Linux packaging solution of this century (e.g. flatpak, snap), one doesn't need to worry so much about how evil a developer is. b) If a software project is truly opensource, there's no reason why the packaging efforts on top of it cannot be opensourced either. What does this mean? That its packaging approach can be forked in the same way as one would do with the sources of the project itself. One could even fork the packaging of a project, not just because it contradicts their principles (e.g. an app that requires too many OS permissions for what it's meant to achieve), but also because it doesn't provide good stability (e.g. an app which keeps sending updates marked as bugfixes when in reality it's bringing new features that introduce regressions). What my opinion boils down to is: - There shouldn't be any difference between downstream and upstream. If you think a developer is not packaging well their software, why not send him a PullRequest instead of to other group of developers (packagers) that didn't write the software originally? - Developers might suck at packaging, granted. But they also suck at UX/UI design, but end up doing the best thing they can. Ultimately a designer might join them to improve the project, why not letting also the helping hand of packagers contribute to upstream directly, instead of setting up their own cult?
  - kick 7y ago
    I'm sorry but, I can't believe we're already on the 20s, and still one has to hear(read) opinions like this. Seems like some members of the opensource community will never learn the lessons from the past. The lessons of the past are that all attempts to draw users away from their distribution's packages end in misery. AppImage is the only half-decent "solution" here, and not even it's very good. And I'm not talking exactly about all the duplicated effort that packagers use(d) to perform in order to distribute software for each distribution. I'm especially referring to the gatekeeper mentality of curating/releasing software. There is no duplicate effort from repackaging software for another distribution. You can literally automate most of it 90% of the time, and when you can't it only takes a minute to write. a) Thanks to the sandboxing technologies used in the Linux packaging solution of this century (e.g. flatpak, snap), one doesn't need to worry so much about how evil a developer is. Not even Apple gets sandboxing perfect, and Red Hat and Canonical demonstrate incompetence all the time. b) If a software project is truly opensource, there's no reason why the packaging efforts on top of it cannot be opensourced either. What does this mean? That its packaging approach can be forked in the same way as one would do with the sources of the project itself. This already happens with the current methods; what you're proposing is a terrible solution to a problem that doesn't exist. One could even fork the packaging of a project, not just because it contradicts their principles (e.g. an app that requires too many OS permissions for what it's meant to achieve), but also because it doesn't provide good stability (e.g. an app which keeps sending updates marked as bugfixes when in reality it's bringing new features that introduce regressions). This demonstrates that you probably aren't aware of how packaging actually works on Linux. Distributions like Debian and RHEL backport security and bugfixes while preventing feature releases. There shouldn't be any difference between downstream and upstream. If you think a developer is not packaging well their software, why not send him a PullRequest instead of to other group of developers (packagers) that didn't write the software originally? "Pull Request" is a GitHub-specific term, and GitHub is awful for packaging. Further, this completely misses the point of packagers. I'm just wondering, does your primary computer run Linux or Windows? Also, your claim "There shouldn't be any difference between downstream and upstream." directly conflicts with your claim on feature updates. Developers might suck at packaging, granted. But they also suck at UX/UI design, but end up doing the best thing they can. Ultimately a designer might join them to improve the project, why not letting also the helping hand of packagers contribute to upstream directly, instead of setting up their own cult? Packaging software is not a cult by literally any possible definition of "cult," literally or figuratively. No packager is going to waste their time contributing to something that actively makes the Linux ecosystem worse. With flatpak and snap, the size per program skyrockets, and the amount of hassle on the user skyrockets, similarly.

kick 7y ago

That's good, and exactly what Drew is recommending! Your distribution's packagers work terribly hard to make your experience good, and so you should absolutely make use of the fruit of their work!