3 ms·

Shouldn't packaging be left to each distributor's experts? As a developer of software you're an expert in whatever your software does--web server, calculator, c

Shouldn't packaging be left to each distributor's experts? As a developer of software you're an expert in whatever your software does--web server, calculator, compiler, whatever. There is no way you can be an expert in your software's functionality and in packaging, especially for more than one distribution. I'm always wary of installing packages not provided by my distribution, just because I have more faith that my distribution's packagers know how to package and they are more likely to use QA processes that will catch packaging bugs. I'd rather compile from source than install third-party packages; I can make my own rudimentary package that would be woefully inadequate for general use but that is perfectly sufficient for my needs.

blueblob 13y ago
I think that depends. ArchLinux packages are almost just bash scripts. People can request fixes. I am sure when you first started programming you weren't an expert and that same logic applies to making packages. Multiple distributions you may be right. I suppose it is fair enough that you would want to install third party packages from source but with most package managers I would guess you could download the package and look at how it is built or at least what files it contains. Using packages can make cleaning up a bad package easier.
- dfc 13y ago
  If there is not a proper Debian package you can use checkinstall or GNU stow. This lets you install from a source tarball and be able to cleanly remove the installation if something happens, good or bad. (proper debian package / botched compile/install)
zdw 13y ago
> Shouldn't packaging be left to each distributor's experts? My take is that any package is better than no package. At least then there's something for a sysadmin, distributor, or other ops person to work with, and it shows that you actively want your software to be packaged. You're the expert on your program and what it needs to work, knowing what the dependencies are, etc - inject that knowledge into the spec/port file and then whatever upstream packager will have even more to work from. > I can make my own rudimentary package that would be woefully inadequate for general use but that is perfectly sufficient for my needs. Why not make that and share it? Having the rudiments around as a starting point to fix and improve is almost always better than having nothing. Think of making packages as a collaboration, rather than something that someone else has to do for you.
nailer 13y ago
> Shouldn't packaging be left to each distributor's experts? I get where you're coming from - there's some apps that want to redefine how packaging or your OS works - but I think it's easier for software devs to learn things like the FHS and packaging than it is for distro maintainers to judge whether an arbitrary piece of software works on not. +1 making your own packages though. More people should do that - if you're smart enough to compile from source, you can easily make an RPM or Dpkg.
forgottenpass 13y ago
There is no way you can be an expert in your software's functionality and in packaging, especially for more than one distribution. The goal of packaging your own software shouldn't be to spin up a public repository of your own, but to get it into distribution repositories. You don't need to be an expert to make decent packages, nor do you have to toil on your own for perfection. Just have something to show for yourself when you get the package reviewed by the distribution maintainers.

blueblob 13y ago

I think that depends. ArchLinux packages are almost just bash scripts. People can request fixes. I am sure when you first started programming you weren't an expert and that same logic applies to making packages. Multiple distributions you may be right. I suppose it is fair enough that you would want to install third party packages from source but with most package managers I would guess you could download the package and look at how it is built or at least what files it contains. Using packages can make cleaning up a bad package easier.

dfc 13y ago
If there is not a proper Debian package you can use checkinstall or GNU stow. This lets you install from a source tarball and be able to cleanly remove the installation if something happens, good or bad. (proper debian package / botched compile/install)

zdw 13y ago

> Shouldn't packaging be left to each distributor's experts? My take is that any package is better than no package. At least then there's something for a sysadmin, distributor, or other ops person to work with, and it shows that you actively want your software to be packaged. You're the expert on your program and what it needs to work, knowing what the dependencies are, etc - inject that knowledge into the spec/port file and then whatever upstream packager will have even more to work from. > I can make my own rudimentary package that would be woefully inadequate for general use but that is perfectly sufficient for my needs. Why not make that and share it? Having the rudiments around as a starting point to fix and improve is almost always better than having nothing. Think of making packages as a collaboration, rather than something that someone else has to do for you.

nailer 13y ago

> Shouldn't packaging be left to each distributor's experts? I get where you're coming from - there's some apps that want to redefine how packaging or your OS works - but I think it's easier for software devs to learn things like the FHS and packaging than it is for distro maintainers to judge whether an arbitrary piece of software works on not. +1 making your own packages though. More people should do that - if you're smart enough to compile from source, you can easily make an RPM or Dpkg.

forgottenpass 13y ago

There is no way you can be an expert in your software's functionality and in packaging, especially for more than one distribution. The goal of packaging your own software shouldn't be to spin up a public repository of your own, but to get it into distribution repositories. You don't need to be an expert to make decent packages, nor do you have to toil on your own for perfection. Just have something to show for yourself when you get the package reviewed by the distribution maintainers.