On Mon, 24 Oct 2011 10:10:10 +0300 Eugene V. Lyubimkin wrote: [...] > > The user should have (approximately) equivalent pins for both package > > managers. > > That's impossible if there are different pin priority systems.
Well, but I hope there will be a way to tell cupt that:
(A) version v1 of package P1 (which *is* currently installed) must not
be upgraded
(B) package P2 (which is currently *not* installed) must not be
installed, whatever version is considered
These are the basic rules that apt-listbugs injects into the apt
pinning preferences.
If there's a way to express such rules for cupt, then apt-listbugs
will be able to be useful for cupt users.
If not, then I will have to document that cupt is not fully supported
by apt-listbugs and that cupt users should not expect apt-listbugs to
work properly for them...
>
> > 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'.
I think that the condition "apt is installed" is satisfied on almost
any Debian box...
I tried
$ aptitude -s --purge-unused install apt_ aptitude_ cupt
It said that 14 packages need to be removed and 6 recommendations need
to be broken, in order to do this.
Even reportbug depends on apt...
This may of course change in the future, but I am under the impression
that you'll still find apt installed on most Debian boxes for quite some
time.
Moreover, the condition "cupt is installed" does not necessarily mean
that the system administrator regularly uses cupt to manage packages.
I don't think that apt-listbugs can figure out whether it should deal
with apt pinning preferences or with cupt pinning preferences.
Hence, if there are two distinct pinning preferences schemes,
apt-listbugs should try to *simultaneously* deal with both of them
(if at all possible).
Finally, even if we find a way to have apt-listbugs figure out which
scheme it should use, there is always the possible scenario of a user
switching from apt(itude) to cupt or vice-versa.
That user should not lose previously set pinning preferences!
[...]
> 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.
If I understand correctly, you are saying that apt-listbugs should
generate rules (such as A and B above) in a package-manager-agnostic
format and then convert them into package-manager-specific forms.
I am not sure that this could work well: what if a user manually
modifies the package-manager-specific configuration, without updating
the package-manager-agnostic configuration accordingly? apt-listbugs
would begin working with a "distorted" vision of the actual package
manager configuration...
--
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
pgpQ6kX8NPduU.pgp
Description: PGP signature
