Bug 220637 - Review Request: fedora-livecd - This package defines the contents of Fedora live CD's
Summary: Review Request: fedora-livecd - This package defines the contents of Fedora l...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-DEADREVIEW
TreeView+ depends on / blocked
 
Reported: 2006-12-22 17:52 UTC by David Zeuthen
Modified: 2013-03-06 03:48 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-22 21:43:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Zeuthen 2006-12-22 17:52:54 UTC
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 22:57:25 UTC
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 17:08:31 UTC
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 17:45:50 UTC
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 18:08:03 UTC
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 18:12:11 UTC
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 18:31:19 UTC
(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 20:02:44 UTC
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 16:10:04 UTC
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 13:22:08 UTC
If by 2, I meant 10, then yes (darn kde-3.5.6 release!), review forthcoming.

Comment 10 Rex Dieter 2007-01-19 13:48:37 UTC
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 14:08:07 UTC
> 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 14:31:24 UTC
For consistency, I think /etc/livecd/ should be named /etc/livecd.d/.

Comment 13 Rex Dieter 2007-03-01 16:43:04 UTC
ping, address items from comment #10 and comment #11, and I'll APPROVE this.

Comment 14 Jeremy Katz 2007-03-22 20:37:10 UTC
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 21:43:55 UTC
I think we should just drop it. Closing this bug. Thanks for the review anyway!


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