[Bug 249522] Review Request: sepostgresql - Security-Enhanced PostgreSQL

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request:  sepostgresql - Security-Enhanced PostgreSQL


https://bugzilla.redhat.com/show_bug.cgi?id=249522


kaigai at kaigai.gr.jp changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |ASSIGNED
               Flag|needinfo?                   |




------- Additional Comments From kaigai at kaigai.gr.jp  2007-08-27 14:49 EST -------
(In reply to comment #46)
> Rereading the Conflicts Guidelines with your comments in mind I think I see a
> point of confusion.  The "Implicit Conflicts" section highlights the fact that
> implicit conflicts are never acceptable.  It says that all conflicts must be
> explicit (marked with Conflicts: PKG).
I might have a bit misunderstandings.

> This package comes closest to the "Binary Name Conflicts" section.  In that
> section, two alternatives are given: Rename the files (in this case you would
> also have to use a different port) or use alternatives to manage the dual 
install.

If possible, I want to avoid to apply the renaming approach, because it requires
us unnecessary differences from the native PostgreSQL, and the difference may
degrade the quality of package.

However, it seems to me that using alternatives is also overdoing approach,
because SE-PostgreSQL is a software to provide an advanced experimental feature
and has much less users than the native PostgreSQL.

> This package is a prime candidate for alternatives as it creates binaries that
> are commandline compatible with postgresql-server and needs to use the same
> port.  You'll need to talk to Tom Lane (tgl redhat.com; now CC'd), the
> postgresql maintainer about how he feels about doing that with the main 
postgres
> package.  He might also have a different idea on how to make the packages co-
exist.
> If you and tgl decide that Conflicts really is the best way to go, present 
your
> reasoning to the Packaging Committee (fedora-packaging redhat.com) so they can
> consider adding another case where "Conflicts: PKG" is allowed. 

I also want to hear his opinion.

In my opinion, we should add the third case to apply Conflicts: tag.
When the package provides an experimental feature based on existing package,
it can use Conflicts: tag to separate from the native package.

It may correspond with the filename conflicts cases, but applying alternatives
between the experimental package and the native package is like as comparison
between a giant and an ant. It's not a realistic way.

> As a side note: I think that using rm to clean up files that you don't want to
> include in the package is much cleaner than using
>   %define _unpackaged_files_terminate_build 0
> Turning off the check is using a bigger stick than necessary.  Turning off the
> check means that you won't be warned of cases where the build changes and 
starts
> creating differently named binaries or new files that you actually want to
> install.  Using rm will target specific files so it's more future proof.

At the first, I didn't use "_unpackaged_files_terminate_build", but I had to put
massive 'rm' commands.
I can remove it and remove unnecessary files, but I don't know whether it is
simple, or not.

Thanks,

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.