[RFC] Deprecate @srcdir in pkg_install manifests
Garrett Cooper
yanefbsd at gmail.com
Sun May 9 04:11:10 UTC 2010
On Sat, May 8, 2010 at 8:44 PM, Garrett Cooper <yanefbsd at gmail.com> wrote:
> On Sat, May 8, 2010 at 8:25 PM, Garrett Cooper <yanefbsd at gmail.com> wrote:
>> Hi Arch and Portmgr,
>> Found another item that I'm proposing for removal -- @srcdir. Now,
>> first off, here's what it does (from pkg_create):
>>
>> @srcdir directory
>> Set the internal directory pointer for _creation only_ to
>> directory. That is to say that it overrides @cwd for package
>> creation but not extraction.
>>
>> This construct:
>>
>> 1. Isn't used anywhere in /usr/ports's pkg_plist* files.
>> 2. Isn't used in /usr/src .
>> 3. Is semi-broken in pkg_create as it's treated as a really awkward
>> special case, like so:
>>
>> else if (p->type == PLIST_CWD || p->type == PLIST_SRC)
>> fprintf(totar, "-C\n%s\n", p->name);
>>
>> So if I specify @srcdir multiple times, pkg_create will fall in on itself.
>> 4. It over-complicates things, as the -p option basically already sort
>
> Correction -- -s and -S handle this functionality:
>
> -s srcdir
> srcdir will override the value of @cwd during package creation.
>
> -S basedir
> basedir will be prefixed to all @cwd during package creation.
Grr... this isn't nearly as simple as I hoped. -s is the controlling
factor for @srcdir:
/* If a SrcDir override is set, add it now */
if (SrcDir) {
if (Verbose && !PlistOnly)
printf("Using SrcDir value of %s\n", SrcDir);
add_plist(&plist, PLIST_SRC, SrcDir);
}
I'll talk this over with flz, but it's definitely obfuscated design.
>> of provides this level of functionality; the only pro for doing this
>> that I can think of is if someone had tainted vs untainted files that
>> they wanted to install, then using @srcdir with a custom manifest and
>> directory would simplify things. I argue that if they're doing that,
>> they should be using a chroot or a jail anyhow because package
>> maintainers would potentially unnecessarily taint the system with
>> their environment and the packages wouldn't be necessarily as safe to
>> redistribute.
>> Another item I'll be talking about with flz and other folks at
>> BSDCan, but I wanted to see if anyone had any concerns that they
>> needed to air here before a final decision was made by portmgr.
Thanks,
-Garrett
More information about the freebsd-arch
mailing list