SF.net SVN: gar:[23769] csw/mgar/pkg/openssl/trunk/Makefile

[Maciej (Matchek) Bliziński]

On Fri, Jun 6, 2014 at 12:35 AM, Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
> Hi Maciej,
>
> We already talked about this case on IRC: the file
> /etc/opt/csw/ssl/openssl.cnf is provided by CSWopenssl-utils but it is
> registered as /etc/opt/csw/ssl/openssl.cnf.CSW in the pkgmap of the package
> as the real /etc/opt/csw/ssl/openssl.cnf is created at install time using
> the cswpreserveconf class.
> So it's indeed a false alarm as there is a package that provides this file
> (the package itself) and there will be no dangling symlink when the package
> is installed.

We can argue about what's a false alarm and what isn't, what I'm
saying is that if you look at the contents of the package, that
contents is bad (dangling symlink is in fact there), and that bug is
corrected by the postinstall script. In an exaggerated example, you
could have a package that has a totally messed up content, and then
postinstall kicks in and patches and fixes everything. That would be
wrong, wouldn't it? This dangling symlink is a mild example of that.

> That can probably be fixed in a another way (but I am not sure I understood
> your proposition, is it about creating a custom class action script to
> handle the creation of the symlink /opt/csw/ssl/openssl.cnf ->
> /etc/opt/csw/ssl/openssl.cnf ?).

CAS creates /etc/opt/csw/ssl/openssl.cnf, right? So why shouldn't it
create /opt/opt/etc/ssl/openssl.cnf too?

Maciej