Re: CONFLICTS variable is terrible

[Aleksey Cheusov <cheusov%tut.by@localhost>]

 >> 1) TONS of packages do not set CONFLICTS variable properly.

> Yes, it is.
I personally think that missed CONFLICTS is critical bug and
most of them MUST be fixed before 2008Q4 happens.

What's your plans?
For this one day noone even tried to use/test wip/pkg_conflicts.

 >> 2) I wrote wip/pkg_conflicts to automate checks for CONFLICTS.

> It's nice, but seems some redundant.
> For example, ap13-* v.s. ap22-*.
I think wip/pkg_conflicts works correctly here.

An algorithm is easy. If packages A and B have common file FILE and
A/Makevile doesn't list B in CONFLICTS, then
    ----- A -----
    Missed: B (FILE)
is printed

Formally speaking ap13-* and ap22-* are different completely independant 
packages.
So, what's wrong?

But I know about different problem:
1) Suppose A conflicts with B
2) Suppose A1, A2,...,An depends on A
3) Suppose B1, B2,...,Bm depends on B
4) 1+2+3 ==> (A and Ax) conflict with (B and By), for any x and y

wip/pkg_conflicts doesn't use this fact (yet).

hint: In your case apache-1.3 and apache-2.2 do not conflict.

 >> 3) Why not to remove CONFLICTS variable at all?

> How to detect CONFLISTS before installation from source?
Filenames from currently installed package (before unpacking) should be checked
against filenames stored in database.

> And how about conflicts with older version, already resolved with current 
> version?
Missed conflicts found by wip/pkg_conflicts shows much more serious problems
than just missed CONFLICTS variable. The real problem is that
there are several completely different reasons, why packages have common 
filenames.

1) They may provide the same functionality. Solution: pkg_alternative framework
   created years ago but still rarely used (is it already dead?).
   Ex: lang/spidermonkey vs. lang/ossp-js vs. lang/js
2) In-tree commonly used libraries, like zlib, libedit and libsigsegv etc.
   should NOT be used in pkgsrc packages.

      0 ~>pkg_online_find PLIST:exact:lib/libopts.la
             autogen -   The Automated Text and Program Generation Tool
           tcpreplay -   Replay saved tcpdump or snoop files
      0 ~>pkg_online_find PLIST:exact:lib/libffi.la
              g-wrap -   Tool for generating guile wrappers for C code
              libffi -   Foreign function interface
                pnet -   DotGNU Portable.NET (development tools)
      0 ~>

   Instead, building should always be done
   with external library. At least for security reasons.
   Ok, almost always... and in this case static linking whould be preferred
   to avoid unnecessary and unexpected conflicts.
3) Fix is possible in pkgsrc. Ex: projclock vs. pclock
4) Badly named tools/files. Maybe upstream should be notified
5) /usr/pkg/bin/subdirectory? or even /usr/pkg/subdirectory/*?
   E.g. wip/heirloom-* packages place their files to /usr/pkg/heirloom/*
   Ex: sysutils/9base
6) <Unsorted>

-- 
Best regards, Aleksey Cheusov.