On Sun, 16 Oct 2011 17:12:43 +0300 Eugene V. Lyubimkin wrote: [...] > On 2011-10-16 12:35, Francesco Poli wrote: [...] > > Mmmmmh... > > This looks like much more work than it would appear at a first > > glance... :-( > > Indeed I was too optimistic. Still, > > > (A) it has to check whether a given package is already pinned in > > /etc/apt/preferences, in order to make the interactive command-menu > > work correctly > > 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. What if the user wants to use apt(itude) for some tasks and cupt for other ones? Or else (more common scenario, I think), what if the user uses apt(itude) and then decides to switch to cupt, and maybe later decides to switch back to apt(itude)? Or vice-versa? The user should have (approximately) equivalent pins for both package managers. Hence, apt-listbugs should try hard to generate and manipulate pin preferences that cause equivalent effects on both apt(itude) and cupt. Clearly, as long as cupt tries hard to share pin preferences with apt(itude), this is automatic and requires almost no additional actions from apt-listbugs. On the other hand, if cupt begins to use a distinct configuration file with different syntax and semantics, apt-listbugs will have to take care of both configuration files and figure out how to reconcile possible inconsistencies between them... The other possible strategy is to explicitly document that cupt is not supported and may fail to work well with apt-listbugs: I would *not* be happy to conclude that there's no other choice than this. I would love supporting cupt as far as possible. But, obviously, the primary goal is supporting apt(itude). It's *apt*-listbugs, after all! [...] > > But what about (A)? What if a package is pinned for Apt, but not for > > Cupt? Or vice-versa? Please remember that configuration files may be > > edited by hand by the (super-)user, hence it may always happen that a > > package is pinned for one package manager, but not for the other one... > > That's a hardest part I guess. I'd suggest not to mix different schemes > and run the package manager part two times for each mode (if both are > installed; if some of them is not installed, don't call the function > with respective parameters). 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. [...] > Back to the my proposal, indeed it requires more work that I thought, > and I will understand if you won't want to implement the changes. 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... It's not much lack of willingness to implement the changes, I was saying, it's more a matter of understanding if and how the whole thing can be done properly. > Thanks > for consideration in any case. You're welcome! :-) -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgp4gC2DBJtC0.pgp
Description: PGP signature
