cvs commit: ports/devel/linux-kmod-compat Makefile distinfo
rizzo at icir.org
Fri Feb 2 20:46:23 UTC 2007
On Fri, Feb 02, 2007 at 09:21:29PM +0100, Pav Lucistnik wrote:
> Luigi Rizzo píse v pá 02. 02. 2007 v 12:14 -0800:
> > On Fri, Feb 02, 2007 at 08:55:29PM +0100, Pav Lucistnik wrote:
> > > Luigi Rizzo píse v pá 02. 02. 2007 v 11:35 -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.
> > >
> > > I think the reason stated in the Makefile on NO_PACKAGE line is bogus.
> > You are right. Fixed now.
> > > Surely you can build it, and move the binaries to another machine
> > > running same OSVERSION ...?
> > Pardon me but have you read what this thing does ?
> > This is the do-build target from the Makefile:
> > do-build: # nothing to build here, just a chance to update the source.
> > there are no binaries built, just a tarball extracted and copied to the
> > destination directory, with no extra files.
> > If you make a package you just create a reformatted tarball with
> > the same content of the original distribution. Makes no sense.
> > you can just as easily download the original.
> Of course it makes sense. It allows user to install it using the
> standard package mechanism. No deal it's just repackaging of vendor
> tarball. We have several ports taht install documentation in this
maybe they are stable packages. This one is changing frequently now.
Anyways, it's my code, it's my choice. You can delete this and
another thousand ports if you don't like the idea of NO_PACKAGE
> > Now if you want to make packages for the children ports (gspca.ko,
> > qc511.ko and so on) that's another story and for those the pkg-plist
> > is fully compliant, i am just unclear on the licensing issues
> > (probably all it takes is add in the package a reference to the sources)
> > and again, i think the modules are too experimental now to be
> > distributed as binaries.
> Note that by not having the package for linux-kmod-compat, you also
> prevent packages for the actual drivers from happening.
why is that ? the dependency is BUILD_DEPEND, so as long as the build
machine has it, the drivers can be packaged by individually
removing the NO_PACKAGE line when it is safe to do so.
> > > > > 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
> > >
> > > Considered asking someone to maintain the port for you? So you could
> > > fully devote to the coding.
> > I did, in the commit log:
> > http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/linux-kmod-compat/Makefile
> I mean, _before_ spending all the time and committing half finished
i was trying to save others a bit of work and learn something.
As for "half finished", this seems a bit of an overstatement.
We are just discussing on the content of a single file, pkg-plist
(or a few lines in the Makefile to build it at pre-install time),
and that was a deliberate choice of mine to have it this way now
and reconsider the choice at due time.
More information about the cvs-ports