Bug 220637

Summary: Review Request: fedora-livecd - This package defines the contents of Fedora live CD's
Product: [Fedora] Fedora Reporter: David Zeuthen <davidz>
Component: Package ReviewAssignee: Rex Dieter <rdieter>
Status: CLOSED WONTFIX QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bugzilla, katzj, mclasen, rdieter, sundaram
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-22 17:43:55 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    

Description David Zeuthen 2006-12-22 12:52:54 EST
Spec URL: http://people.redhat.com/davidz/livecd/spec/fedora-livecd.spec
SRPM URL: http://people.redhat.com/davidz/livecd/src/fedora-livecd-6-1.src.rpm 
Description: This package defines the contents of Fedora live CD's.

The three RPM's from this SRPM is used by the livecd-tools package to create Fedora specific live CD's. See bug 220635 for livecd-tools review.
Comment 1 Jason Tibbitts 2006-12-22 17:57:25 EST
I note that all three packages generated from this spec own /etc/livecd, and
ownership of a single directory by multiple packages is generally something to
be avoided.  Since there's a clear dependency chain (fedora-livecd is required
by the two subpackages), the base package should probably own it and the others
shouldn't.
Comment 2 David Zeuthen 2007-01-04 12:08:31 EST
The way this is going to work is that any package (for example a live CD
installer or 3rd party live CD definition files) can drop configuration files in
/etc/livecd. As such, there might not be a clear dep chain. 

Also, for Xen liveOS flavors one might instead install fedora-livecd-xen (that
Provides: fedora-livecd) and fedora-livecd-desktop and then you don't have that
dep chain.

So I'd prefer each package to own the directory /etc/livecd. I *think* our
guidelines allow for this so is it OK to import the SRPM as is?

Thanks for the review!

Comment 3 Tom "spot" Callaway 2007-01-04 12:45:50 EST
fedora-livecd-desktop Requires: fedora-livecd-gnome
fedora-livecd-gnome Requires: fedora-livecd

Seems like a very clear dep chain to me. Only fedora-livecd should own the
directory, no need for the subpackages to do it too.
Comment 4 David Zeuthen 2007-01-04 13:08:03 EST
Consider that an upcoming livecd-tools-installer package will also put files
there and this package can be installed without having any fedora-livecd*
packages installed.

(actually this makes sense; you will be able to install the
livecd-tools-installer package and use an existing system to install an .iso
file to e.g. a USB hard disk)
Comment 5 David Zeuthen 2007-01-04 13:12:11 EST
To clarify comment 4, my question is should the livecd-tools-installer also own
the /etc/livecd directory even though it *might* be installed at the same time
as fedora-livecd (sometimes it might, sometimes not). I guess that would work

I guess I'm fine with just having fedora-livecd owning /etc/livecd; we can
always fix up things later if there are side effects.

OK to import with this change? Or are there other issues? Thanks.
Comment 6 Ralf Corsepius 2007-01-04 13:31:19 EST
(In reply to comment #5)
> To clarify comment 4, my question is should the livecd-tools-installer also own
> the /etc/livecd directory even though it *might* be installed at the same time
> as fedora-livecd (sometimes it might, sometimes not). I guess that would work
> 
> I guess I'm fine with just having fedora-livecd owning /etc/livecd; we can
> always fix up things later if there are side effects.
Standard soapbox answer to such kind of questions:
- If several packages share a common directory, and if they depend on each other
in a strict hierarchy, then letting the "root package" own this dir is sufficient.
- If they don't depend on each other in a strict hierarchy, all of the packages
must own this directory.

Comment 7 David Zeuthen 2007-01-04 15:02:44 EST
So, in response to comment 6, and because of the fact that I'll have a new
package  soon that will drop files in /etc/livecd (that will not depend on other
such packages) .... it seems like all packages dropping files in /etc/livecd
should own the directory?
Comment 8 Rex Dieter 2007-01-09 11:10:04 EST
I can review this within the next day or 2 (if no one gets to it first in the 
meantime)
Comment 9 Rex Dieter 2007-01-19 08:22:08 EST
If by 2, I meant 10, then yes (darn kde-3.5.6 release!), review forthcoming.
Comment 10 Rex Dieter 2007-01-19 08:48:37 EST
Packaging-wise, pretty simple, offhand:

SHOULD: +BuildArch: noarch  

SHOULD: the Autoreq: 0 here is dubious at best, problematic at worst, for (very)
little gain.  I'd recommend omitting it.

MUST: make /etc/livecd owned only by (main) fedora-livecd pkg.

MUST: all subpackages +Requires: %{name} = %{version}-%{release}

MUST: (sub)packages installing items into /usr/share/backgrounds need
Requires: desktop-backgrounds-basic
(-gnome subpkg in particular)
Comment 11 Rex Dieter 2007-01-19 09:08:07 EST
> MUST: all subpackages +Requires: %{name} = %{version}-%{release}
ammendment:
-gnome MUST: Requires: %{name} = %{version}-%{release}
-desktop MUST: either
Requires: %{name} = %{version}-%{release}
Requires: %{name}-gnome
or
Requires: %{name}-gnome = %{version}-%{release}
whichever is more esthetically pleasing to you.

Make these changes, and I'll approve this.
Comment 12 Jim Radford 2007-01-19 09:31:24 EST
For consistency, I think /etc/livecd/ should be named /etc/livecd.d/.
Comment 13 Rex Dieter 2007-03-01 11:43:04 EST
ping, address items from comment #10 and comment #11, and I'll APPROVE this.
Comment 14 Jeremy Katz 2007-03-22 16:37:10 EDT
This package is dead at this point; we've changed the livecd process such that
it's not used anymore.  Unless David really wants to import the FC6 packages
here, I think we should just let it drop.
Comment 15 David Zeuthen 2007-03-22 17:43:55 EDT
I think we should just drop it. Closing this bug. Thanks for the review anyway!