tech-pkg archive
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index][
Old Index]
enforcing pkgsrc/category/$PKGBASE
Wouldn't it be nice if each package was always in a directory
which matched the $PKGBASE. It would make it much easier and
quicker for tools (and people) to map back and forth between
them, and also allow us to (potentially) cleanup the DEPENDS
format:
DEPENDS+= www/p5-Catalyst-Plugin-ConfigLoader>=0.19
rather than the current rather ugly:
DEPENDS+= p5-Catalyst-Plugin-ConfigLoader>=0.19:../../www/p5-Catalys
t-Plugin-ConfigLoader
The flies in this proposed ointment are:
a) *-devel packages which provider newer compatible versions
of a base package
b) ap2?-* packages which can generate apache 1.x 2.0 or 2.2
packages
c) py-* packages, which generate different output packages
based on the version of python installed
Taking these in order:
a) We could push implicit support for these into pkgsrc. So
a package foo-devel[0-9]*-* would automatically conflict
with foo-*, and be treated as identical when matching
depends
b) We have a somewhat confusing mix of ap{,2,22}-*
packages in pkgsrc. an ap22-* package will only work
with apache22, and ap-2 package will work with
apache2 and *may* work with apache22, and an ap-*
package will work with apache apache and may work
with none, one, or both of apache2 and apache22. We
currently have ap{,2,22}-* packages. Splitting them
up into explicit ap{13,20,22} directories which each
only generate a package for a single version of
apache would add 22 and make it obvious from looking
at the pkgsrc tree what versions are supported
c) py-* packages. This fly has teeth. There are 216
py-* packages and unlike the apache packages which
tend to need different Makefiles between apache
versions, we have a nice setup which can build
multiple versions from a single directory based on
python version. We *could*:
- Let python directories be an exception
- Add explicit package directories, a number of
options on this, none of them nice:
<Can_skip>
- add 400+ packages and rename the current, using
clever includes pointing to the default version (but
we'd need to churn every package when we changed
the default). Ick.
- add 400+ packages and rename the current,
duplicating versions & DESCR etc everwhere. Ick.
- Add 600+ packages, using clever includes to the
current packages, but that leaves us with these
oddball package directories which never build
anything. Ick
- add 400+ packages and rename the current, all
with clever includes pointing to data under
lang/pythin. Ick
</Can_skip>
Anyone have any thoughts? Have I missed something
which is not 'ick'?
~
Home |
Main Index |
Thread Index |
Old Index