[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