> There were two reasons I stopped doing this.
>
> One reason is that it isn't clear that this is needed. At least the
> Debian and RPM communities have already solved these problems to their
> satisfaction.
I disagree in two ways:
- As a developer who builds & distributes packages, I'd love a tool which
abstracts platform-specific packaging, the same way autoconf & automake
abstract platform-specific building. I don't want to become a member of
every packaging tool's community; I just want it to be easy to build a
variety of package formats from a single source tree & package description.
- As an end user who builds & installs software on my own systems, I would
rather build & install a package appropriate to my system than "make
install". (That way, you can tell which package a given file came from,
which files are in a given package, and where a given package came from,
and you don't have to keep the source tree around in case you ever want to
do a "make uninstall".) I would much rather learn how to type "make deb"
or "make deb-install" or "make package" (or whatever) than learn how to
build my own packages on the three different packaging systems I use.
(Bothersome enough already to learn & remember three different sets of
commands for querying the package databases!)
> Introducing another tool would probably just make things harder for
> Debian/RPM package maintainers.
How so? (If they don't want to use the tool, they don't have to!) If the
concern is that ease-of-building might lead to a confusing proliferation of
semi-broken packages, I think there are reasonably easy ways to tell whether
a given package is the one you built & can vouch for.
--Rusty