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. 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? -Jim ________________________________ From: Stephanie Daugherty<mailto:sdaughe...@gmail.com> Sent: 8/14/2015 6:21 AM To: T.J. Duchene<mailto:t.j.duch...@gmail.com>; dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [DNG] Devuan and upstream On Thu, Aug 13, 2015 at 4:06 PM T.J. Duchene <t.j.duch...@gmail.com> wrote: > > 1. You can't mark a package as "Do not install." APT simply does not give > you the option. > > Heaven knows, there are a lot of people who dislike things like network- > manager, and do not them to install for any reason. > > Someone might say - wait you can put a hold on packages. That's true, but > that does not stop packages from being installed. It only says which > version > is preferred. There is no option for "none". > > You can block packages with APT pinning, but using pinning is very > esoteric. > > There's a less obvious, but more reliable solution that holding or pinning., and that is the dummy package. equivs makes this pretty easy to create - you simply need a package marked that conflicts with the undesired software, or if you prefer, one which tells the system that package is already installed, so that you can ignore the dependency at your own risk and without any pestering from apt. . > 2. Whenever an update has bug, you cannot rollback to the previous version > of > the package. It is always assumed that the latest version is correct. In > the > real world, we know that is not always true. > Sure you can, just not with apt. dpkg is still the actual package manager, and will happily install older versions for you, so long as you take care of the dependencies on your own. In many cases the previous packages are still sitting around in apt's download directory, but if not, they can usually still be found in the archives. Besides, unless you follow unstable, this doesn't happen often enough to be a serious concern, because of Debian's rigid "no functionality changes in stable, only fixes" policy. The situation in both of these cases should be better, but arguably, if it's a direction Devuan decides to go in, it would be best to do so as extensions to apt rather than reinventing the wheel, so as to keep as much compatibility with Debian as possible and continue to use Debian as upstream whenever possible. Without Debian as an upstream, the task of maintaining Devuan even at parity with Debian would be all but impossible for the small team of maintainers and developers currently part of Devuan. Unless a very large portion of the Debian community jumps ship, and Devuan becomes the base of Debian rather than the other way around, I think this will have to continue for the foreseeable future.
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng