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.duchene@gmail.com>
Sent: ‎8/‎13/‎2015 1:06 PM
To: dng@???<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@???
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng