packaging is not much more work than building something from source. it's all the same process until the end step where you use the packaging tools to assemble the whole thing. it can get tedious when you end up having to package dependencies as well. but it's mainly grunt work, and none of the work is special to packaging. without packaging everyone would have to do the same work.
my favorite packaging tool was conary. it has automated packaging to such an extent that in most cases all that is needed is to tell it the command to run the build and install processes for that application. it figures out everything else by itself. which files are documentation, what are libraries. what are dependencies. one thing it did was to split a package into components. there is a :doc component, a :mysql component and others, which were especially useful for optional dependencies. if you didn't use mysql you could leave out the :mysql component and install the package without a mysql dependency.
where with deb or rpm i had to manually figure out what goes where if i wanted to split up a package, in conary that process was mostly automatic.
and, to address another comment here, conary worked just fine with the FHS. i do not think that the FHS was or is the problem. not being able to install multiple versions of a library is a limitation of the packaging tools. conary didn't have a problem with that, as long as packages were built without file conflicts conary did not get confused when you had multiple versions of the same package.
it's a pity that the distribution built on it did not survive.
that said, we do need containerization, but for a completely different reason: trust and security.
my favorite packaging tool was conary. it has automated packaging to such an extent that in most cases all that is needed is to tell it the command to run the build and install processes for that application. it figures out everything else by itself. which files are documentation, what are libraries. what are dependencies. one thing it did was to split a package into components. there is a :doc component, a :mysql component and others, which were especially useful for optional dependencies. if you didn't use mysql you could leave out the :mysql component and install the package without a mysql dependency.
where with deb or rpm i had to manually figure out what goes where if i wanted to split up a package, in conary that process was mostly automatic.
and, to address another comment here, conary worked just fine with the FHS. i do not think that the FHS was or is the problem. not being able to install multiple versions of a library is a limitation of the packaging tools. conary didn't have a problem with that, as long as packages were built without file conflicts conary did not get confused when you had multiple versions of the same package.
it's a pity that the distribution built on it did not survive.
that said, we do need containerization, but for a completely different reason: trust and security.