As someone who's background is in Slackware, I know where automatic package dependency resolution has its good points and bad points.
Pkgtools is very basic. Everything is left to the system administrator to resolve, but SlackBuilds.org offered a solution. It allows packages to have certain triggers like WITH_JPEG=yes ./<name>.SlackBuild, but sbotools took it farther by scripting everything to work off the README, .info files, and the build scripts to resolve things at a controllable level without things getting complicated. Very akin to CRUX's and BSD's ports. Devuan should follow the Debian methodology, but equally it should forge it's own path away from Debian. It doesn't need to draw from any other distribution like Funtoo, CRUX, Slackware, or anything other distributions, other than seeing what people are using and in need of. The wants will be many, but what users need will matter most of all. Devuan should be Devuan. That's all I can say on that for now. -Jim ________________________________ From: T.J. Duchene<mailto:t.j.duch...@gmail.com> Sent: 8/13/2015 1:06 PM To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: [DNG] Devuan and upstream Everyone of course is welcome to comment but the question is really for the Devuan team. Is the general plan is just to copy Debian, or are there plans to make more changes than just systemd? Debian APT is an example. It's a good manager, but it falls short in some key areas that are not unreasonable to ask from a package manager. 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. 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. The reason I am asking is that Debian clearly has no plans to fix any of these problems. They've been around for a decade or more. I wonder if Devuan does have any plans to correct Debian's shortcomings, regardless of what upstream does? For myself, before I'd consider spending the effort to look at ways of fixing some things, I'd want to know that those efforts would be received or if they would go against the overall plan of absolutely remaining compatible with Devian upstream. For example, mentioning the problems above - if Devuan intends to eventually break away from Debian, then redesigning the packaging process would be the way to go, because you could handle rollbacks and other concerns. If Devuan plans to remain as close to Debian as possible, then perhaps a GUI attached to synaptic to simplify pinning for the average user might be in order instead. I'd just like to get some idea of what contributions to Devuan might be made in the future. T.J. _______________________________________________ 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
