On 15/08/2015 00:19, James Powell wrote:
> Slackware is maintained by 3 core people with extra help as needed. The
> rest of the packages are pushed by the community at large contributing.
> Devuan doesn't have to maintain every package possible. That's ludicrous
> to think so.
>
> Debian got in over its head by allowing this. Thousands upon thousands
> of packages that required a committee to oversee.

While this might be true to an extent, you can also view it this way:
the organisation and structure of Debian, the project, allowed it to
scale to 1000 developers who could maintain 20000 packages without
stepping on each others toes too often. That's a considerable
achievement--how many other projects have been able to achieve an
equivalent scale?

Now I think there may have been benefits to separating the "base" system
from "everything else", and indeed it was discussed on several occasions
in Debian, but this never happened for various reasons. In retrospect,
I think it would have been a good move.

> Honestly, what is needed by a distribution? Look at Slackware or BLFS
> that's a lot of packages, but it's manageable by a small team. Why can't
> Devuan follow suit? There doesn't need to be a bagillion packages
> maintained by the main devs. If the rest need to be passed back to the
> community at large, then do it. This also hits the point of why do we
> need 5 different for things like, for example, SDL packages for -bin,
> -lib, -doc, -dev, -src, and such? One package is easier to maintain than
> five individual ones. It lightens the load significantly, especially for
> the poor soul having to make 5 or more different scripts for 5 packages
> from the same source tarball. Yes, it's nice to have small packages for
> embedded stuff and small disks, but do you really want to raise the
> workload of the maintainer that much?

I think this is barking up the wrong tree. Maintaining multi-binary
source packages isn't the huge burden you're making out. There's just
one script to build all the binary packages, so the overhead on that
side is unchanged. The separate packages are generally just lists of
files/directories to be copied into each package, and this is fairly
easy to maintain.

Having everything in a single package is inflexible and wastes disc
space. Undoing all the effort that went into this in the first place
would be a significant regression.

That said, I do think multi-binary package generation could be automated
for the common cases. It's pretty trivial to distinguish headers,
libraries, documentation, translations, source, debug symbols from the
filesystem locations they live in. This is also something which has
been discussed over the years. The tool changes to accommodate it are
not insignificant though.


Regards,
Roger