> > In the concept I have in the mind all pin stanzas will not be final, so > > I think this check can be totally disabled in "cupt" mode. > > This looks problematic to me. > I mean: I don't think that apt-listbugs should have distinct modes > depending on the package manager the user wants to use. [...] > But, obviously, the primary goal is supporting apt(itude). > It's *apt*-listbugs, after all!
Makes sense. > The user should have (approximately) equivalent pins for both package > managers. That's impossible if there are different pin priority systems. > As I said above, I am under the impression that apt-listbugs needs to > *simultaneously* take care of each different scheme that must be > supported. > Currently, only one scheme is supported and everything is simple. > Adding support for a second scheme requires code which is able to > figure out how to handle weird situations that may arise when the two > configuration files disagree on something. I was under impression that it's possible not to mix modes. Different schemes are inconsistent from the very beginning, they disagree on almost everything even if there would be no configuration files. I imagined it as 'if apt is installed, run in apt mode, forget about any non-apt schemes as if they don't exist', 'if say (cupt) is installed, run in cupt mode, forget about any non-cupt schemes as if they don't exist'. > It's not much lack of willingness to implement the changes, even though > I may admit that time is a bit scarce down here, and I would prefer to > consume it in fixing apt-listbugs own bugs, rather than in adding code > that could create more problems than the ones it is intended to > solve... Of course. I understand your position. Things will don't change until the archive freeze, let's see if I can figure something by that time. For the design point of view, it could be so that utilities like apt-listbugs work with the own state file with an own format in a package-manager-agnostic way, and for each package manager there is a tiny submodule which converts that file/data to a package-manager-specific configuration file every time the state file/data changes. For that to work, utilities should not change its behavior depending on the other (user) preferences, which I believe would be better. But that's my humble opinion. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
