[pacman-dev] Some of my TODO entries to discuss

[Nagy Gabor]

> Well, this should be fixed with
> http://www.archlinux.org/pipermail/pacman-dev/2007-September/009271.html
> Please follow the thread, and let me know your -U and -S opinion (there are
> 2
> different ways: the Vmiklos-way and the ~Arch-way). If I get enough feedback,
> I
> will implement your choice.
> My opinion:
> -%REASON% should show the _initial_ reason (which is computed after the
> _first_
> install of the package), and later -S/-U will keep this reason (without
> examining that this is a pulled dependency, or listed in the target list by
> user) [this is the ~Arch way]: I prefer this, because [1.] if the user don't
> want to update his whole system with -Su (because he has low-bandwidth net
> for
> example), he can update a dependency (by doing "pacman -S dependency")
> without
> change its reason field to explicit; [2.] and unneeded dependency->explicit
> conversion may prevent pacman from orphan detection (can happen in
> Vmiklos-way)
> and missing dependency->explicit conversion just may list some extra orphan
> packages (can happen in ~Arch-way); [3.] explicit is the
> "final"/irreversible
> state of a package
> -IMHO we need an ability to change the reason fields in localdb /whatever
> you
> choose/, because users may want to mark/unmark their "important" packages
> (and
> pacman's automatism is unpredictable ;-)
> 
> Bye, ngaba
> 

As I started thinking about the implementation, I ran into some older questions,
which we haven't discussed yet; but it is necessary to make decisions, because
the they affect the solution of this problem, too.

1. Should we resolve target<->target conflicts by removing the package from the
target list?
I started to like Xavier's opinion ( == no, we shouldn't), because I realized
that if we don't resolve them, then we don't(?) need pmsyncpkg_t struct.
[my answer: dunno, Xavier: no]
2. So shall I kill pmsyncpkg_t struct? 
[my answer: yes; however, this is a big job; but this is the first step we need
if we want to implement the "universal" transaction; contra: we loose the "glue"
between the replacer and the to-be-replaced packages <- so the real question is:
do we need this glue?]
3. %REASON% handling
[my answer, Xavier: ~Arch-way]

Bye, ngaba

----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/