Bug 225680 - Merge Review: desktop-backgrounds
Merge Review: desktop-backgrounds
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: desktop-backgrounds (Show other bugs)
23
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jef Spaleta
Fedora Package Reviews List
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 12:56 EST by Nobody's working on this, feel free to take it
Modified: 2016-12-20 06:55 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 06:55:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 12:56:34 EST
Fedora Merge Review: desktop-backgrounds

http://cvs.fedora.redhat.com/viewcvs/devel/desktop-backgrounds/
Initial Owner: davidz@redhat.com
Comment 1 Jef Spaleta 2007-02-12 17:05:18 EST
remove from doc section
%dir %{_datadir}/gnome-background-properties

add Requires: gnome-backgrounds

because you place an xml file down in /usr/share/gnome-background-properties/
which is already owned by gnome-backgrounds package.

As per the review guidelines, directories can not be owned by multiple packages.

-jef
Comment 2 Mamoru TASAKA 2007-02-12 21:56:05 EST
(In reply to comment #1)
> remove from doc section
> %dir %{_datadir}/gnome-background-properties
> 
> add Requires: gnome-backgrounds
> 
> because you place an xml file down in /usr/share/gnome-background-properties/
> which is already owned by gnome-backgrounds package.
> 
> As per the review guidelines, directories can not be owned by multiple packages.
> 
> -jef

Ah..
This guidelines should read as:
----------------------------------------------------
The directory must not be owned if there is other package
* which owns the directory
* and the package _is required_ by this package
----------------------------------------------------
So this package should not own %{_datadir}/gnome-background-properties
if this package _really_ requires gnome-backgrounds.

Actually my system has gnome-backgrounds-basic but does not
have gnome-backgrounds. So in this case this package _must_
own %{_datadir}/gnome-background-properties .
Comment 3 Mamoru TASAKA 2007-02-12 21:57:36 EST
s|gnome-backgrounds-basic|desktop-backgrounds-basic|
Comment 4 Jef Spaleta 2007-02-13 02:53:07 EST
lets be very very clear

http://fedoraproject.org/wiki/Packaging/ReviewGuidelines

MUST: Packages must not own files or directories already owned by other packages.

right now.. this rule is broken... both packages own the directory. This is not
allowed under the current packaging review guidance.  It does not matter that
the current depchains allow it. As a matter of policy this is broken behavior.
This behavior is cleaned up by removing the ownership of the directory from one
package and making it require the other.  

-jef
  
Comment 5 Mamoru TASAKA 2007-02-13 03:09:16 EST
Yes, so this "other packages" means "other packages required
by this package", not "other packages not really required by
this package".

So  having two directories owned by several packages is actually
_allowed_ . The more important thing is that "every directories
should be owned at any install option somehow". So this package
does not need gnome-backgrounds, then this package _must_ own
%{_datadir}/gnome-background-properties. This is a _MUST_.
Comment 6 Mamoru TASAKA 2007-02-13 03:14:57 EST
Oops.. s|two directories|a directory|
Comment 7 Jef Spaleta 2007-02-13 03:19:34 EST
your interpretation completely disregards the rule-of-thumb example providing in
the review guidance.

It's an established policy, a policy which was re-affirmed in discussion at
FUDCon among multiple reviewers and attendant members of the packaging
committee.  If you want to have a wider discussion of its interpretation, feel
free to bring it up in the appropriate mailinglist. Having a running debate in
this review ticket is counter-productive.  If the maintainer feels there is a
particular need to break this particular policy, that maintainer can provide a
justification as per the review guidance.

good day
Comment 8 Mamoru TASAKA 2007-02-13 03:28:34 EST
No, this policy is not changed actually.
Comment 9 Mamoru TASAKA 2007-02-13 04:05:47 EST
Again, 
* this package does not require gnome-backgrounds
* Also my system does not have gnome-backgrounds

Please read carefully the section "File and Directory Ownership" of
http://fedoraproject.org/wiki/Packaging/Guidelines .
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines only
shows the summary.
Comment 10 Karsten Hopp 2007-02-13 04:12:32 EST
re: comment #5 'So  having two directories owned by several packages is 
actually_allowed_'

Mamoru, please read http://fedoraproject.org/wiki/Packaging/ReviewGuidelines 
again:

- MUST: A package must own all directories that it creates. If it does not 
create a directory that it uses, then it should require a package which does 
create that directory. The exception to this are directories listed explicitly 
in the Filesystem Hierarchy Standard.


This means that each directory not listed in the FHS can have only one owner.
Comment 11 Patrice Dumas 2007-02-13 04:18:58 EST
(In reply to comment #10)

> - MUST: A package must own all directories that it creates. If it does not 
> create a directory that it uses, then it should require a package which does 
> create that directory. The exception to this are directories listed explicitly 
> in the Filesystem Hierarchy Standard.
> 
> 
> This means that each directory not listed in the FHS can have only one owner.

No, this means that there is no need to have an explicit dependency on 
filesystem even if filesystem owns some of the directories used by the
package.
Comment 12 Jef Spaleta 2007-02-13 04:25:35 EST
okay... instead of having a sidebar conversation in a bug ticket... it is time
to take this to the mailinglist for general discussion. Clearly there is a
difference of opinion. How about we spare the poor package maintainer the bloody
details of this, and move this to the fedora-extras-list for discussion. I
sincerely invite Mamoru Tasaka to start a thread on fedora-extras-list
concerning the matter. And I would encourage anyone with an opinion to
participate in the mailinglist discussion.  Doing a prolonged discussion in
here, is counter-productive.

-jef
Comment 13 Mamoru TASAKA 2007-02-13 04:30:33 EST
I always check fedora-devel fedora-extras fedora-maintainers
fedora-list fedora-packaging etc as much as I can. However
always the discussion is held on midnight... (I live in Japan,
EST + 14h)
Comment 14 Patrice Dumas 2007-02-13 04:40:50 EST
I brought up this issue here:

https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00308.html

there was no definitive answer. This issue is still open. In the review 
I do I insist that no directory should be owned and I let the packager the
choice to own the directory or depend on the not-really needed package.

Maybe this issue should be risen once again on another list.
Comment 15 Matthias Clasen 2007-02-15 19:07:00 EST
Preferences show be visible again with gnome-menus-2.17.91-2.fc7
Comment 16 Matthias Clasen 2007-02-15 19:08:12 EST
Argh, wrong bug. Sorry
Comment 17 Matthias Clasen 2007-08-10 23:11:23 EDT
In the meantime, we have decided that desktop-backgrounds-basic should own
/usr/share/backgrounds, and thus we've added a dependency on
desktop-backgrounds-basic to gnome-backgrounds. 

Consequently, desktop-backgrounds-basic should own
/usr/share/gnome-background-properties, too.
Comment 18 Cole Robinson 2015-02-11 15:35:57 EST
Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:

  https://fedorahosted.org/fesco/ticket/1269

If you don't know what merge reviews are about, please see:

  https://fedoraproject.org/wiki/Merge_Reviews

How to handle this bug is left to the discretion of the package maintainer.
Comment 19 Jan Kurik 2015-07-15 11:27:01 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 20 Fedora End Of Life 2016-11-24 05:17:55 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 21 Fedora End Of Life 2016-12-20 06:55:41 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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