Date: Wed, 23 Jul 2014 23:40:34 -0400 From: Adam Weinberger <adamw@adamw.org> To: Dmitry Marakasov <amdmi3@amdmi3.ru> Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Adam Weinberger <adamw@FreeBSD.org>, ports-committers@freebsd.org Subject: Re: svn commit: r362545 - in head: . games/bsdgames games/bsdgames/files Message-ID: <5F5D5006-4EA2-48B4-9728-8553CAEA6163@adamw.org> In-Reply-To: <20140723204623.GB34571@hades.panopticon> References: <201407221445.s6MEjf7o025973@svn.freebsd.org> <20140723183649.GA34571@hades.panopticon> <2FF4267F-CF53-41A6-B4A3-9B9D7A630014@adamw.org> <20140723204623.GB34571@hades.panopticon>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Jul, 2014, at 16:46, Dmitry Marakasov <amdmi3@amdmi3.ru> wrote:
> * Adam Weinberger (adamw@adamw.org) wrote:
>=20
>>> I advice to revert this.
>>>=20
>>> This is not hier(7)ful as there's no var neither under /usr nor =
under
>>> /usr/local.
>>>=20
>>> This is not better, as you should expect /usr/local to be mounted
>>> read-only along with /usr, so changing data should only reside under
>>> /var.
>>=20
>> Both you and itetcu brought up that last point to me... it=92s a =
really good point that I hadn=92t considered when I made the move.
>>=20
>>> If @sample doesn't do the thing, just don't use it, do not invent =
hacks.
>>> It's broken in many ways and I've planned to start discussion on =
that.
>>=20
>> It=92d be helpful to have the PHB say how to properly handle things =
outside of ${PREFIX}. There=92s essentially no information on it, nor on =
the differences in how pkgng and pkg_tools handle it. Not even anything =
in CHANGES about it.
>>=20
>> It=92s not even about =93inventing hacks,=94 so much as having to =
figure out the right way to do things by trial and error, because =
documentation doesn=92t exist.
>=20
> My idea is that it should be done by pkg-install/pkg-deinstall
> scripts. These are clear (no need for single line chains as in
> `@exec foo && bar && baz'), reusable (may just copy scripts from
> other ports), are not affected (essentially removed) by `make plist`,
> do not induce false positives in sanity checkers and will work
> regardless of pkg-plist infrastructure or policy changes.
>=20
> pkg-plist, otoh, stays limited to plain file list with mixins of
> predefined keywords inner workings of which you shouldn't care
> about which work relative to PREFIX.
I love having commands in the plist. It gives you one simple, portable =
place to put all the pre/intra/post installation commands. chown in a =
pkg-install will fail for non-root users, but pkg will do the right =
thing. Sure, you could do the same thing before with a special and =
specific @exec/@unexec incantation, but many ports either did it wrong =
or gave up and skipped it altogether, removing .conf files on every =
update.
I think =91make check-plist=92 is infinitely better for updating a plist =
than =91make plist=92 though I do agree that portlint needs some love to =
catch it up with recent paradigm changes.
I think that the solution for reusability and consistency is MORE =
keywords, so that all ports do things the same, predictable way. And so =
that changes can be propagated to all ports immediately, rather than =
hunting through pkg-install scripts to find out why one port is doing =
something unexpected.
I=92d posit that what creates a consistent and dependable end-user =
experience is not muting installation commands, macros like @sample and =
@shell, thorough use of OPTIONS, letting pkg carry the burden of =
ensuring that things work properly for non-root users, and ensuring that =
porters know how we now handle things that were traditionally =
disastrously difficult, such as conf files, empty directories, and =
things outside of $PREFIX.
# Adam
--=20
Adam Weinberger
adamw@adamw.org
http://www.adamw.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5F5D5006-4EA2-48B4-9728-8553CAEA6163>