[pacman-dev] libalpm data structures

Xavier shiningxc at gmail.com
Wed Oct 31 08:42:03 EDT 2007

On Mon, Oct 29, 2007 at 07:23:25PM -0500, Dan McGee wrote:
> On 10/23/07, Xavier <shiningxc at gmail.com> wrote:
> > On Sun, Oct 21, 2007 at 09:33:42PM +0200, Nagy Gabor wrote:
> > > Well, I overlooked something. pmconflict_t is reserved for
> > > file-conflicts only, and pmdepmissing_t is used for conflicts?! (UGLY)
> > > So here is a little patch which renames pmconflict_t to pmfileconflict_t
> > > and alpm_conflict_* to alpm_fileconflict_*.
> >
> > I also found this confusing when I first saw it, so I think I like your change :)
> >
> > > pmconflicttype_t was removed
> > > from pmfileconflict_t structure, because type can be determined with
> > > (ctarget == "").
> >
> > Well, I'm less sure about that, but I don't know really. What do others
> > think?
> I'm just confused overall here, and here is what I think should be
> done in some way or another. File conflicts and target (package)
> conflicts are completely different things, and should in now way be
> handled with the same struct.
> I don't know what a ctarget is- that is a terrible name. Let's get rid of it.
> I feel like we can simplify dep handling/target conflicts down to one
> logical group, and file conflicts down to another. The file conflicts
> stuff is easy; the package conflicts/depends is not so easy.
> Package conflicts:
> type packageconflict {
>    Package 1 (name, version)
>    Package 2 (name, version)
>    (and some magic to handle depends, conflicts, and the current mod operator)
> }
> File conflicts:
> type fileconflict {
>    String filename
>    Location 1 (a package)
>    Location 2 (a package OR the filesystem)
> }
> Thoughts? I think Nagy found some code here that definitely isn't up
> to snuff, we just need to make sure we fix it in the right way.

That's not too far away from what it looks after Nagy's patches:
struct __pmconflict_t {
       char package1[PKG_NAME_LEN];
       char package2[PKG_NAME_LEN];

struct __pmfileconflict_t {
       char target[PKG_NAME_LEN];
       char file[CONFLICT_FILE_LEN];
       char ctarget[PKG_NAME_LEN];

But maybe it would be better to extend the package conflict structure like
you said above.
IMO it would mostly help for the current conflict resolving code, which is
quite ugly.
I think it helps less after Nagy's resolve conflict patch, which makes this
code simpler / cleaner, but I would need to look more into this to be sure.

About file conflict structure, it's quite similar to what you said :
file is the filename
target is the location 1 : a package
ctarget is the location 2 : filesystem if equals to "", a package otherwise

So what bothered me mostly is the actual representation of location 1 and
location 2. What did you have in mind exactly?

More information about the pacman-dev mailing list