[pacman-dev] how should pacman choose? flags? groups? ...
ngaba at petra.hos.u-szeged.hu
ngaba at petra.hos.u-szeged.hu
Thu Jul 12 14:52:45 EDT 2007
> I install acidrip which depends on mplayer, I most likely want mplayer to be
> pulled, not mplayer-svn.
OK, I understand this, and you are right, but I think, there is no
definition for package "priority", if you _define_ that provide is not
as "strong" as the "canonical" package, I will follow that rule.
(Anyway, I think only one mplayer version should be exist in repos)
Let me explain an other (theoretical) example:
Suppose that there is two kernel package in the sync repos: "vanilla"
and "beyond" (RIP). And there are module packages compiled for them,
such as nvidia-vanilla and nvidia-beyond, both provides nvidia. User
does "pacman -S nvidia-utils" (which depends on nvidia). User has the
beyond kernel installed, but pacman decides that it will install
nvidia-vanilla and thus the kernel vanilla... probably the user doesn't
want this. We can minimize the number of installed dependencies in
alpm_resolvedeps or minimize the needed disk space etc. etc. but that
wouldn't worth our effort.
A bit off, for package maintainers:
Personally I like the way, that I described above, and sometimes this
"binary gentooish" packaging way would be nice. I mean, sometimes there
are some very interesting but mutual ./configure options; in these
cases multiple binary packages can be very helpful (-alsa, -oss, -gtk1,
-gtk2, ...) and user could choose. These packages can be "identical"
through provide.
Any idea for this? flags? (special) groups (beyond and vanilla in our
example) which helps pacman in the decision? [pacman must choose from
nvidia-vanilla and nvidia-beyond and if these packages "flagged" by the
groups vanilla and beyond, pacman can do a "-Qg vanilla" and "-Qg
beyond" and it will see, that the installed vanilla group is empty, so
probably the user wants to install a beyond package]
Bye, ngaba
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
More information about the pacman-dev
mailing list