Jeff Spaleta wrote:
On 8/31/06, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote:
Actually, I think the point was if you want to create Dodo Linux 7 based
on Fedora Core 6 it's easier to substitute the Dodo Linux id if the
package/file providing it has a neutral name. No need to scan scripts and
deps for fedora references - just replace the release file in the package
with a new one.
Its not JUST the release file. take a really good hard look at the
fedora-release package contents... everything in there is fedora
distro specific. From the eula to the yum repo definitions. If anyone
package defines that an install IS fedora.. its the fedora-release.
I am aware of what is in the package..
Having a downstream distro rename a package, when ALL the real files
in that package MUST change isn't too much to ask.
I never said it was too much to ask. In fact, I specifically said that it's not
a big deal. It's merely picking up a pebble. I was simply thinking out-loud
that it might be a tad better to do things this way.
The only thing I am aware of which explicitly depends on the
fedora-release provide statement are the repo-release packages for 3rd
party repos.. like livna. Which by the way makes perfect sense..
because the existence of a versioned fedora-release is pretty much the
only way the rpmdb knows that its actually a fedora release.
$ rpm -q --provides fedora-release
config(fedora-release) = 5-5
indexhtml
redhat-release
fedora-release = 5-5
Couldn't system-release just provide fedora-release, dodo-release, or whatever?
Its irrationally to completely genericize the entire packagespace, its
only going to lead to confusion. Seems to me it would be harder for
distros to comb the contents every package in Core looking for fedora
specific content which should be replaced before redistribution, then
to have Fedora keep the packages with fedora-specific content in a
well-defined namespace. The entirety of the regular files in
fedora-release and fedora-logos are fedora specific content and should
remain as named to make it clear they are fedora specific content.
I'm not confused as to what would be needed and anybody who knows enough to
create their own custom distro based on FC shouldn't have too much trouble with
figuring out what needs to be replaced either.
What you want to do to make life easier for downstream distros is make
sure is that nothing in Core and Extras strictly depend explicitly on
the provides fedora-release and fedora-logos. And guess what they
don't. The only silly provides/depends that I can see is initscripts
requirement that /etc/redhat-release be on the system... which is a
legacy rhl/rhel issue anyways and its not even Fedora inspired. And
I'm sure that there is a way to have initscripts recoded so that
requirement can be generalized to require /etc/system-release instead
without loss of initscripts funtionality for fedora or rhel. If you
want to work on something to help downstream distros.. go work on
that.
I wasn't specifically looking for something to "go work on". Just saying "Hey,
this might be better." And if whomever takes care of the redhat-whatever or
fedora-whatever packages wants to change them to system-whatever. Cool.. If
not. Oh well..
This is not the Generic Linux Distribution Project, and you must
expect there to be Fedora specific content which is inappropriate for
downstream distributors to reuse. By using a well defined fedora-
package prefix for packages which contain fedora specific content
(such as the eula, or fedora specific repository configurations, or
trademarked materials) you are actually making it easier for the
downstream distros to figure out exactly which packages contain
content which they need to review before redistributing.
No, it's not the "Generic Linux Distribution Project". But at the same time,
nobody is walking around pounding their chest yelling, "Hey! We're Fedora! Make
sure you know it!"
Generic package names don't change much WRT the updates (or difficulty of making
updates) which are necessary when creating a downstream distro.
Ultimately, it doesn't bother me much. Most of the aforementioned packages
don't even affect me. I don't need them in an embedded system.
Cheers...Paul...
--
---
Paul B Schroeder <pschroeder "at" uplogix "dot" com>
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
