tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: postgresql packages, PG_SUBPREFIX and CONFLICTS

I did the historical aspects of why CONFLICTS are unhelpful earlier.
Onto the strategic reasons now.

If we're going to have any sort of indication that a package installs
files with the same name as another package, let's have it centrally. 
It doesn't belong in the individual pkgsrc entries.  That way doesn't
scale, it gets stale quickly, and is not easy to find at all.  With
bulk builds and binary package repositories, we can have this
information held centrally, (that's if we decide that we do want to
hold the information at all).

On a more abstract level, a pkgsrc entry (the Makefile, DESCR, PLIST
files etc) relates to the package, or, more correctly, steps to be
taken to build a package, and to wrap it up into a binary package.  It
doesn't relate to any other package, except for specifying pre-reqs to
get it to build.  The pkgsrc entry can also relate to parts of this
package which will be used by other packages - the files,
maybe the options framework - but it doesn't relate in any way to any
other package.  Neither should it.

The CONFLICTS entry, however, is the first place in the pkgsrc entry
which relates to a different binary package.  It may be possible to
point to the alternates framework as well for this, but I feel
alternates are completely different, and are meant to allow preferences
to be specified, and don't impose restrictions.

CONFLICTS impose constraints on what people can do with packages for
no good reason.  I may want to install diffrent postgres packages side
by side for comparison purposes, or for easier migration.  I really
resent that I can't do it because ...  well, I'm not sure exactly why
CONFLICTS entries are desired.

Now given that we have no real reason for CONFLICTS in pkgsrc nowadays
(see previous email), that it doesn't fit into the architecture well,
it imposes arbitrary constraints on what people can do with packages
for dubious benefit for one person, let alone the majority of users, I
think we should be working to reduce the number of CONFLICTS
statements in the Makefiles (preferably to the number 0).

Please note that I'm not saying that you shouldn't pursue this angle
if it is useful for you - just that if you do, it should be in a
centrally held file which could be machine-generated, downloaded, and
certainly not spread across pkgsrc Makefiles. And it should not impose
constraints on everyone else and their usage of pkgsrc.


Home | Main Index | Thread Index | Old Index