This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 501518 - Rfe: Creating of a filesystem subpackage
Rfe: Creating of a filesystem subpackage
Product: Fedora
Classification: Fedora
Component: heartbeat (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-05-19 10:56 EDT by Jochen Schmitt
Modified: 2009-08-03 11:58 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-03 11:58:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jochen Schmitt 2009-05-19 10:56:47 EDT
On BZ #401130 we reviewing a package which contains a subdirectory of %{_sysconfdir}/ha.d in the %files stanza without heatbeat may be required for this package. 

Because regarding of the packaging guuidlines each file/directory should owned by a package, I want to suggest the creation of the filesystem subpackage for heatbeat.
Comment 1 Kevin Fenzi 2009-05-19 12:47:16 EDT
It seems overkill to make a filesystem package just for one single directory. ;( 

Perhaps drbdlinks could also own this directory? 
I think this is another case of: " Although the rule of thumb is the same: own all the directories you create but none of the directories of packages you depend on, there are several instances where it's desirable for multiple packages to own a directory."

heartbeat doesn't require drbdlinks and drbdlinks doesn't require heartbeat. 

What do you think?
Comment 2 Robert Scheck 2009-05-21 19:29:11 EDT
Interesting idea which makes sense to me. Others?
Comment 3 Robert Scheck 2009-05-23 19:54:30 EDT
From the conversation on #fedora-devel at Freenode:

[01:15:47] < rsc> nirik: ideas for the /etc/ha.d thing?
[01:16:10] < nirik> my idea was to have them both own it.
[01:16:24] < nirik> Splitting out a filesystem package for one dir seems like overkill to me.
[01:20:08] < rsc> nirik: I could create a drbdlinks-heartbeat subpackage, but that also seems to be overkill for a single symlink
[01:20:34] < nirik> yeah, whats the drawback to both owning it? should work I would think.
[01:21:03] < rsc> nirik: if we can do that, it would be perfect to me. But guidelines etc.?
[01:21:49] < nirik> well, I think it's ok guidelines. Look at the packageguidelines page where it talks about directory ownership. I think this is not the same as the examples there, but is similar.
[01:23:55] < rsc> nirik: you're right, the example is closed to it.
at point 2.
Comment 4 Robert Scheck 2009-05-23 21:24:12 EDT
I decided to depend with drbdlinks on heartbeat, as this seems to be the
most common setup when looking around.
Comment 5 Kevin Fenzi 2009-06-06 01:56:45 EDT
ok, Can we close this bug now?
Comment 6 Robert Scheck 2009-06-06 15:16:47 EDT
Yes, we can.
Comment 7 Jochen Schmitt 2009-06-25 15:32:15 EDT
I have reopend this bug, because I have done some work to implemnent a separate filesystem subpackage on your package and have checked in in the devel branch.
Comment 8 Kevin Fenzi 2009-06-25 15:37:40 EDT

There's no reason for it. 
drbdlinks just requires heartbeat. 
The filesystem package is just one directory. 
It diverges from upstream packaging and all other rpm versions. 

Is there any reason to have this? 
Please revert or tell me at least why?
Comment 9 Robert Scheck 2009-06-26 04:21:23 EDT
I'm also lacking the need for this, because drbdlinks simply will depend on
heartbeat in Fedora as this is the most common setup, as far as I got told. I
don't see any need to change this behaviour.
Comment 10 Kevin Fenzi 2009-08-01 17:43:54 EDT
I don't think there is any need for a fs package at this time. 

Can we go ahead and close this now?
Comment 11 Robert Scheck 2009-08-02 08:48:37 EDT
Yes, please.

Note You need to log in before you can comment on or make changes to this bug.