[pacman-dev] libalpm data structures

[Kevin Piche]

On Wed, 2007-10-31 at 13:42 +0100, Xavier wrote:
> 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];
> };


Not a criticism since I haven't done a code review - I assume it's just
legacy.  I'm curious as to why package names are duped and put on
multiple lists instead of pointers to package structs one per package.


> 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?
> 
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev