4 ms·

Good lord. I'll never understand why people promote this project, since it's main feature is that he's doing it wrong. The complexity he's trying to avoid exist

by dima55 3y ago

Good lord. I'll never understand why people promote this project, since it's main feature is that he's doing it wrong. The complexity he's trying to avoid exists for a reason, not because people like complexity. OP: post here: https://lists.debian.org/debian-jobs/ https://lists.debian.org/debian-jobs/

bravetraveler 3y ago
Please heed this - FPM is basically versioned tarballs. It's only useful for the most simple/contrived scenarios Actual package specs require effort for good reason. It's not just an archive... but interdependence, steps to perform on (un)installation, changelogs, and so on. There are some helpers already provided, ie: RPM macros. Sure, they're esoteric, but show me a specialization that isn't. Refer to the Fedora packaging guidelines and enjoy life.
viraptor 3y ago
It depends on what you want as a result. Do you want the shortest path to "dpkg -i the-result.deb" working on your server, or do you want a package complying with debian standards around behaviour and file locations, with packaging/source changelog split, potentially upstreamable? Because the second one is a lot more work, but few people actually need that.
- dima55 3y ago
  The second one is more work and it's what you want. Because it gets stuff into the main archive that everybody benefits from in the future. Otherwise your project is a series of hacks that create an unmaintainable mess.
  - pxc 3y ago
    It is also a branding problem, imo. Part of the reason I prefer software from distro repositories is because those conventions the distro maintainers enforce help ensure that packages won't do stupid things and break my system. Especially with DEB and RPM, where the packaging format supports arbitrary hooks that run as root, this is a big deal. High quality packages that meet distro standards will inspire confidence in customers' sysadmins. Substandard packaging may do disservice to your core software's brand, if your actual software is more solid and thoughtful than the packaging.
  - viraptor 3y ago
    No, sometimes you really don't care about that. Some software will always stay internal. Some is so specific that it will never get to a distro. Some is just experimental and providing standards-compliant packaging for it is a waste of time. And that's when FPM can be useful if you want to go that way.
    - wink 3y ago
      Yeah, FPM is great not for official/public packages (or libraries) but for "for some reason our $org installs internal (or patched, or just self-built OSS) stuff via package manager" and most often even all the versions, like /opt/foo-1.0, /opt/foo-1.1 and so on. It solves this problem very well.
      - bravetraveler 3y ago
        I'd say it solves it passably, in the simplest and most minimalistic way possible to still call them packages, technically. I question how one gets here, nay, the 'problem' we're solving. Presumably there's config management involved already capable of shipping bits. ie: the repo definitions to find these hackjob packages, or deliver them directly. If this is what you're willing to invest, go Slackware at it - use a tarball. You aren't gaining anything notable by throwing an archive at a packaging format. The meta that FPM ignores is what provides packages their value! If changelogs were at least a part of it, I'd be a bit more accepting. Otherwise, I see it mainly as misappropriation. Best case, naive and well served. Worst case, giving the impression of better distribution than actually exists An organization that does packages, but leaves this as the answer, fails itself and the members. Over 90% of the purpose is dutifully ignored/not standardized
pxc 3y ago
A thousand times this. As someone who has been fascinated with package management for a long time, my first reaction to FPM was horror. FPM is by and for people who resent package management and want to avoid actual packaging work, not people who are passionate about doing it well. You want people who, when tasked with creating a package for a distribution format that is new to them, look not to tools like this, but to the conventions and standards of successful distros which use that format as examples. You want 'native' engagement with those packaging formats, not hacks like FPM. The parent commenter's suggestion is an excellent one.

by dima55 3y ago

bravetraveler 3y ago

Please heed this - FPM is basically versioned tarballs. It's only useful for the most simple/contrived scenarios Actual package specs require effort for good reason. It's not just an archive... but interdependence, steps to perform on (un)installation, changelogs, and so on. There are some helpers already provided, ie: RPM macros. Sure, they're esoteric, but show me a specialization that isn't. Refer to the Fedora packaging guidelines and enjoy life.

viraptor 3y ago

It depends on what you want as a result. Do you want the shortest path to "dpkg -i the-result.deb" working on your server, or do you want a package complying with debian standards around behaviour and file locations, with packaging/source changelog split, potentially upstreamable? Because the second one is a lot more work, but few people actually need that.

dima55 3y ago
The second one is more work and it's what you want. Because it gets stuff into the main archive that everybody benefits from in the future. Otherwise your project is a series of hacks that create an unmaintainable mess.
- pxc 3y ago
  It is also a branding problem, imo. Part of the reason I prefer software from distro repositories is because those conventions the distro maintainers enforce help ensure that packages won't do stupid things and break my system. Especially with DEB and RPM, where the packaging format supports arbitrary hooks that run as root, this is a big deal. High quality packages that meet distro standards will inspire confidence in customers' sysadmins. Substandard packaging may do disservice to your core software's brand, if your actual software is more solid and thoughtful than the packaging.
- viraptor 3y ago
  No, sometimes you really don't care about that. Some software will always stay internal. Some is so specific that it will never get to a distro. Some is just experimental and providing standards-compliant packaging for it is a waste of time. And that's when FPM can be useful if you want to go that way.
  - wink 3y ago
    Yeah, FPM is great not for official/public packages (or libraries) but for "for some reason our $org installs internal (or patched, or just self-built OSS) stuff via package manager" and most often even all the versions, like /opt/foo-1.0, /opt/foo-1.1 and so on. It solves this problem very well.
    - bravetraveler 3y ago
      I'd say it solves it passably, in the simplest and most minimalistic way possible to still call them packages, technically. I question how one gets here, nay, the 'problem' we're solving. Presumably there's config management involved already capable of shipping bits. ie: the repo definitions to find these hackjob packages, or deliver them directly. If this is what you're willing to invest, go Slackware at it - use a tarball. You aren't gaining anything notable by throwing an archive at a packaging format. The meta that FPM ignores is what provides packages their value! If changelogs were at least a part of it, I'd be a bit more accepting. Otherwise, I see it mainly as misappropriation. Best case, naive and well served. Worst case, giving the impression of better distribution than actually exists An organization that does packages, but leaves this as the answer, fails itself and the members. Over 90% of the purpose is dutifully ignored/not standardized

pxc 3y ago

A thousand times this. As someone who has been fascinated with package management for a long time, my first reaction to FPM was horror. FPM is by and for people who resent package management and want to avoid actual packaging work, not people who are passionate about doing it well. You want people who, when tasked with creating a package for a distribution format that is new to them, look not to tools like this, but to the conventions and standards of successful distros which use that format as examples. You want 'native' engagement with those packaging formats, not hacks like FPM. The parent commenter's suggestion is an excellent one.