One of the things I really appreciate about Slackware (and thusly Vector) is that, with very few exceptions, the packages are built from source code which is unmodified from that available from the originating project's homepages. This minimizes risk of errors creeping into a package and eases the task of customizing a project to my own needs. Better still, it allows me to readily contribute back to a project or otherwise participate in its development.
Randomly scanning through some of the "packages" (actually just scripts) in the Crux repositories, I see that many of them follow this same practice (of obtaining source directly from the project). However, I do not see a ready way to determine if or when this is the case (I had to manually compare the sources specified in the scripts with the projects' source locations); and determining what modifications might have been made to the source if it is from a different location.
So, my first concern is about how this "chain of custody" of package source is to be addressed.
In addition, Crux packaging guidelines seem to specify three practices that are at odds with guidelines of Slackware (and, to my knowledge, Vector):
- Stripping documentation files from the package
- Disabling language support (NLS)
- Separating related programs into multiple packages
It appears that the only benefits of incorporating Crux ports packaging into Vector would be the catalog of available Crux scripts and the fact that a packager doesn't have to search for a project's homepage for source. It seems to me, the first benefit would be better covered by implementation of a repository of Vector-Build scripts (something which would probably be necessary anyway, owing to the differing guidelines between Crux and Vector); and the second benefit is pretty well nullified by the fact that packagers will need to document any disparities between the included sources and those of the originating project (knowledge necessary to the Vectelopers, if not the users).
The NLS problem is easily handled automatically, but for the other concerns, using Crux ports might entail more effort than it saves.