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

[Luigi Rizzo]

On Fri, Feb 02, 2007 at 07:37:55PM +0100, Pav Lucistnik wrote:
> Luigi Rizzo píse v pá 02. 02. 2007 v 10:32 -0800:
> > On Fri, Feb 02, 2007 at 07:19:05PM +0100, Pav Lucistnik wrote:
...
> > > You can't do this. Now, the packages will contain nothing (read: be
> > > useless).
> > 
> > at least for the time being it makes no sense to have a
> > package built for this port, for a variety of reasons
> > (code stability, licensing, etc). So i have put in pkg-descr
> > only enough info to cleanup on deinstall.
> > I am not sure it will _ever_ make sense to have this as a package,
> > when the code becomes stable enough it should should probably
> > become part of the kernel.
> > 
> > did i misunderstand something ?
> 
> Yes.
> 
> First, you break the Good Practices of port making.
> 
> Second, you deny your users a part of the general functionality of the
> ports collection - ie. packages. Users will be unable to install binary

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.

> package from the network, users will be unable to build a package on
> their machines and mass-install it on their other computers. You have no
> rollback on upgrade, if it should fail.
> 
> Plus, you're setting a false impression that other people can get away
> with this in their ports.
> 
> Now there are methods to have the pkg-plist autogenerated. How hard it
> would be?

As for auto-building the pkg-plist, it is not totally automated,
at least judging from Sec. 7.5 of the handbook, and now i really
don't have more time to spend on this exercise.  When the code being
ported will be in a more stable state, as i said in the commit
message, i will reconsider this option, but generating the pkg-plist
from the port's Makefile, because this is the only thing that
makes sense in this specific port (because just checking that
no files are overwritten by others does not help - if someone stuffs
in extra headers in the directory i installed, it may screw up
what the compiler picks up on an #include)

	cheers
	luigi