[Bug 226387] Merge Review: samba

[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: Merge Review: samba


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





------- Additional Comments From ssorce at redhat.com  2007-03-30 11:29 EST -------
(In reply to comment #15)
> Schema:
> Well, maybe just mark the schema file as "%config(noreplace)" ? Openldap does
it for its schema files.

I'll think about that, but schema files are not really configuration files, so
it is suspicious for me.

> Docs:
> > the user can go on the website 
> "Conflicts: area-without-internet-access" ? ;)
Solution: Dload samba-docs :-)

> BTW, "COPYING" IMHO should be in the main sub-package (i.e. in "samba").

Yes, that was an oversight, I think.

> Generally, the recommendation "move big documentation to separate sub-package"
> does dot mean "move all the documentation". Move just _really big_ stuff to it.

Ok, I'll review that.

> Migration:
> > it is absolutely not correct that on of the scripts stop any other just
> > to do the migration
> I mean that each script does migration of its _own part_ of data. Certainly,
if it is possible (i.e. no situation where two different daemons have
simultaneous access to some *.tdb file).

Not really, that is why I want to do all in one place at one time, when I have
control of everything.

> Well, since initscript idea is not suitable, maybe consider triggers? It seems
that:
> 
> %triggerun common -- samba-common < 3.0.24
> stop_all_running_daemons and touch_its_var_lock
> do_the_migration
> 
> cause migration to be performed before any "samba-common < 3.0.24" uninstall,
> which looks more clean than "Requires(pre):" .
> 
> (BTW, if I'm not wrong, according to dependences, old "samba" is removed first,
> then old "samba-common", ..., then new "samba-common" installed, then "samba".
> It seems that if we use "%triggerpostun", not "%triggerun", then
> "stop_all_running_daemons and touch_its_var_lock" is not needed at all...)

No, removal happens _after_ installation on upgrades. Don;t aske me why but I
tested this stuf carefully, and I don;t see, right now, any better way, it works
and I'll keep like that, unless someone can show me a patch and the testing
procedure used to make sure it works :)

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.