4 ms·

That's quite a negative view of the situation. The debian maintainers definitely don't insist that everything has to do things the apt-way. They only insist tha

by Doxin 7y ago

That's quite a negative view of the situation. The debian maintainers definitely don't insist that everything has to do things the apt-way. They only insist that packages for the official repos do so, which seems sensible enough to me. Everyone is still free to build their own deb packages or distribute their applications through install scripts or app images or any one of a hundred thousand different ways to distribute programs. But if you want a package in the official repos you have to play by the rules they set, the primary one being that official packages ought to only depend on official packages. It'd simply be impossible to have any guarantees about the quality of a package otherwise.

lmm 7y ago
It's not just a question of being in the official repos. Even if you're running a private repository, the deb tooling is not suitable for building many kinds of software: it's unwilling to play nice with "external" dependencies, and still single-platform and limited in its functionality.
- pjc50 7y ago
  > unwilling to play nice with "external" dependencies But that's a policy decision - the dependencies should themselves be packages, because that's the only way to guarantee reliability. The inability to install multiple versions is probably the only serious problem with the dpkg model. Even then we might argue that the dependent software should be fixed so that it's not so fussy about specific dependency versions.
  - HorstG 7y ago
    Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed. Of course this is work for application as well as library developers, designing and keeping compatibility is hard. Most would rather build the new shiny, consequences be damned.
    - xchaotic 7y ago
      I think these are noble but naive approaches - we have been developing software for a few decades now and sometimes the software is not compatible without the developer knowing it. You should be able to use whichever version of the software you need.
      - HorstG 7y ago
        "Whichever version you need" comes with the responsibility of providing security and bugfix upgrades in a timely fashion. Almost all developers fail spectacularly at this, with latencies in the order of months. This is clearly not viable.
        AnIdiotOnTheNet 7y ago
        As we are all aware, the most secure software is software that doesn't work at all because of library conflicts.
      - pjc50 7y ago
        > sometimes the software is not compatible without the developer knowing it Sure, but this should be considered either a defect or something highlighted by a major version number jump.
        oblio 7y ago
        Yeah, but who decides if it's a defect? Maybe the defect is subtle and only manifests in rare cases and the upstream rightfully decides that after a risk/payoff analysis, it's not worth fixing it. Or maybe he agrees and fixes it and it's included in distributions 7 years later. I've changed 5 jobs in 7 years (because of life circumstances) and I'm not even a job hopper... How is any commercial shop going to plan around 7 year time frames?
        pjc50 7y ago
        Well, within a debian distribution the Debian developer responsible for the downstream package would get the dependency fixed, either themselves or by badgering the maintainer, and use the fixed Debian version. This gives Debian a consistent set of packages that work together. Yes, it's a lot of work and it's why Debian are behind other distributions and don't include Hadoop. But it reduces the unpleasant surprises. It's effectively part of insisting that it's properly Free software - if you can't maintain your own bugfixed fork, but have to keep going to an external organisation for their version, is it really Free?
  - AnIdiotOnTheNet 7y ago
    > The inability to install multiple versions is probably the only serious problem with the dpkg model. Also can't install to separate disks.
    - thyrsus 7y ago
      That's unlikely. Worst case: examine where the package will put its files, and prep your system with symbolic links to directories residing on a file system on the other disk(s). But that raises the question: why are your file systems sensitive to disk drives? Use a layer (or more) of indirection through LVM and RAID so to make the drive placement opaque and robust.
      - deleted 7y ago
        [deleted]
      - AnIdiotOnTheNet 7y ago
        > why are your file systems sensitive to disk drives? A couple of systems I have at home have a 16GB primary disk, so it is useful to be able to put things on an external disk. I have yet to see any package manager that can actually handle that. > Use a layer (or more) of indirection through LVM and RAID... Yeah, that's a great idea, just introduce more complication and abstraction to make up for a shortcoming in how Linux developers think about applications. Or, just have your programs be self contained in a single file or folder and put them wherever it makes sense.
- rumanator 7y ago
  > it's unwilling to play nice with "external" dependencies This baseless assertion is simply out right wrong. See for example Debian's docs on Private Package Archive: https://wiki.debian.org/DebianRepository/Setup https://wiki.debian.org/DebianRepository/Setup
  - teknopaul 7y ago
    Hear hear. If anything .debs dont care enough where dependencies come from. As long as the package name matches you are good. I have no complaints about debian packaging. I've used lots of different ones. All official packages are signed and its easy to sign your own packages. Maven, on the other hand, is plain scary.
roenxi 7y ago
Here here. And the only thing that makes Debian an interesting brand is the quality consistency of the official repository. If someone doesn't like apt & the main repository they shouldn't use Debian because that is pretty much the only big thing separating Debian from the tens to hundreds of other distros out there. Take apt and the main repo out of Debian and it is basically Linux From Scratch with a bigger team of bugtesters. Distributions aren't 'jealous' about packet management, they are the packet management. It is right there in the name "Debian distribution". The Debian brand, and all linux distro brands, are deeply linked to how they execute packet management to distribute software.

by Doxin 7y ago

lmm 7y ago

It's not just a question of being in the official repos. Even if you're running a private repository, the deb tooling is not suitable for building many kinds of software: it's unwilling to play nice with "external" dependencies, and still single-platform and limited in its functionality.

pjc50 7y ago
> unwilling to play nice with "external" dependencies But that's a policy decision - the dependencies should themselves be packages, because that's the only way to guarantee reliability. The inability to install multiple versions is probably the only serious problem with the dpkg model. Even then we might argue that the dependent software should be fixed so that it's not so fussy about specific dependency versions.
- HorstG 7y ago
  Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed. Of course this is work for application as well as library developers, designing and keeping compatibility is hard. Most would rather build the new shiny, consequences be damned.
  - xchaotic 7y ago
    I think these are noble but naive approaches - we have been developing software for a few decades now and sometimes the software is not compatible without the developer knowing it. You should be able to use whichever version of the software you need.
    - HorstG 7y ago
      "Whichever version you need" comes with the responsibility of providing security and bugfix upgrades in a timely fashion. Almost all developers fail spectacularly at this, with latencies in the order of months. This is clearly not viable.
      - AnIdiotOnTheNet 7y ago
        As we are all aware, the most secure software is software that doesn't work at all because of library conflicts.
    - pjc50 7y ago
      > sometimes the software is not compatible without the developer knowing it Sure, but this should be considered either a defect or something highlighted by a major version number jump.
      - oblio 7y ago
        Yeah, but who decides if it's a defect? Maybe the defect is subtle and only manifests in rare cases and the upstream rightfully decides that after a risk/payoff analysis, it's not worth fixing it. Or maybe he agrees and fixes it and it's included in distributions 7 years later. I've changed 5 jobs in 7 years (because of life circumstances) and I'm not even a job hopper... How is any commercial shop going to plan around 7 year time frames?
        pjc50 7y ago
        Well, within a debian distribution the Debian developer responsible for the downstream package would get the dependency fixed, either themselves or by badgering the maintainer, and use the fixed Debian version. This gives Debian a consistent set of packages that work together. Yes, it's a lot of work and it's why Debian are behind other distributions and don't include Hadoop. But it reduces the unpleasant surprises. It's effectively part of insisting that it's properly Free software - if you can't maintain your own bugfixed fork, but have to keep going to an external organisation for their version, is it really Free?
- AnIdiotOnTheNet 7y ago
  > The inability to install multiple versions is probably the only serious problem with the dpkg model. Also can't install to separate disks.
  - thyrsus 7y ago
    That's unlikely. Worst case: examine where the package will put its files, and prep your system with symbolic links to directories residing on a file system on the other disk(s). But that raises the question: why are your file systems sensitive to disk drives? Use a layer (or more) of indirection through LVM and RAID so to make the drive placement opaque and robust.
    - deleted 7y ago
      [deleted]
    - AnIdiotOnTheNet 7y ago
      > why are your file systems sensitive to disk drives? A couple of systems I have at home have a 16GB primary disk, so it is useful to be able to put things on an external disk. I have yet to see any package manager that can actually handle that. > Use a layer (or more) of indirection through LVM and RAID... Yeah, that's a great idea, just introduce more complication and abstraction to make up for a shortcoming in how Linux developers think about applications. Or, just have your programs be self contained in a single file or folder and put them wherever it makes sense.
rumanator 7y ago
> it's unwilling to play nice with "external" dependencies This baseless assertion is simply out right wrong. See for example Debian's docs on Private Package Archive: https://wiki.debian.org/DebianRepository/Setup https://wiki.debian.org/DebianRepository/Setup
- teknopaul 7y ago
  Hear hear. If anything .debs dont care enough where dependencies come from. As long as the package name matches you are good. I have no complaints about debian packaging. I've used lots of different ones. All official packages are signed and its easy to sign your own packages. Maven, on the other hand, is plain scary.

roenxi 7y ago

Here here. And the only thing that makes Debian an interesting brand is the quality consistency of the official repository. If someone doesn't like apt & the main repository they shouldn't use Debian because that is pretty much the only big thing separating Debian from the tens to hundreds of other distros out there. Take apt and the main repo out of Debian and it is basically Linux From Scratch with a bigger team of bugtesters. Distributions aren't 'jealous' about packet management, they are the packet management. It is right there in the name "Debian distribution". The Debian brand, and all linux distro brands, are deeply linked to how they execute packet management to distribute software.