cvs commit: ports/devel/linux-kmod-compat Makefile distinfo pkg-descr pkg-plist

[Luigi Rizzo]

On Sat, Feb 03, 2007 at 02:39:37PM +0100, Alexander Leidinger wrote:
> Quoting Luigi Rizzo <rizzo at icir.org> (Fri, 2 Feb 2007 11:35:27 -0800):
...
> > As i wrote, the developer of the code being ported (which happens
> > to be me) has stated a few reasons why at this time he does not 
> > want a package made of this port. This is entirely his right, and
> > we have the NO_PACKAGE keyword exactly for this reasons.
> 
> What's the difference between installing it as a package instead of as
> a port? From a high level point of view I don't see a difference. So
> why do you allow to install as a port but not as a package?

because the package would just be a reformatted tarball with the
same exact content of the distfile, and the latter will be changing
frequently now i see no reason to build packages of a volatile
thing. I am not asking for people to agree, since i am just expressing
my preference same as i had written the code under a no-redistribution
license.  This is not a violation of a 'ports' rule.

Besides, it is a transient thing not an immutable decision.

> So in my eyes your life will be more easy with a plist.

Again, the plist was there from the beginning and did cleanup
after itself from the beginning.

i'd rather not debate this longer because the topic has been beaten
to death and also fixed in a hopefully reasonable manner by Alex Dupre
(thanks alex).

What (i think) the port manager want is a pkg-plist that lists
exactly every ENTITY (in their case the ENTITY can only be a file)
meant to be installed by this package, so they can run a variety
of integrity checks e.g. that other programs don't overwrite my
ENTITIES, that I don't overwrite others, the package includes all
of them, and so on.

And this is all good and sound and agreed.

I have exactly the same requirement, EXCEPT that for me one of the
ENTITY is a subtree. I was only asking (or advocating) if there
was a way to support different types of entities. Then as i wrote
in the other email, my pkg-plist would simply become

        @this-is-my-subtree %%DATADIR%%/linux-kmod-compat
        @deltree %%DATADIR%%/linux-kmod-compat

(the former on insertion, the latter on removal) plus two
lines for the other individual file i install.

If we had that:
+ the plist would be in general a lot simpler for all toolkits
  (which often install in their own private subtree, and have
  similar conflict requiremensts as the one i have - #include
  mechanisms that use wildcards and the like, so random addition
  of new files is not acceptable even if it doesn't conflict with
  what the file-based plist says).

+ the plist would be a lot easier to maintain and stable over time
  -> less repository bloat, less chanche to make mistakes,
  less time spent updating it.

+ the checks done by the automated tools would be a lot
  faster because of greater aggregation of information. 
  E.g. to see if a file which is part of a package is
  legitimate,  you don't have to compare it with the 100+
  entries for that subtree, but can stop when you match
  the prefix. Similarly, when you want to run a conflicts
  check, you don't have to repeat it for every single file
  but you do once for the entire prefix (besides giving more
  coverage as you can really tell to leave the subtree alone).

cheers
luigi