8:58 a.m.
Hi,
If you're not interested in mach development or pedantic naming issues
then please delete and skip to the next mail.
The upcoming 0.4.3 release of mach will finally have Fedora Core 1
building support. It will also have n/v/r parsing based on the build
options (since, for example, Matthias Saou used some variables to
construct the Source tags).
There was support added to CVS by some others. I changed some things
though, one of which is the basename for the distribution, which is why
I'm mailing. I've changed it to fedoracore-1-i386. Compare this to
(for rh9) redhat-9-i386.
Also, I had asked Matthias to symlink his RPMS.core to RPMS.os to be in
line with fedora.us, though I've been told fedora.us might change
themselves from RPMS.os to RPMS.core; this allows people to choose to
get Fedora Core RPMS from either freshrpms or fedora.us (Since at work
we have a freshrpms local mirror, I'm forced to using that one :))
Since the actual distro released is Fedora Core 1, however, and I'm
assuming there might be releases of other sets (say, Fedora Freeworld 1)
which might have another base, I wanted to make it explicit that this is
fedoracore and not fedora.
I could be persuaded to change this before the release, but I want to
make sure people understand why I chose this for now and that I don't
intend to change it anymore after the release...
Thomas
3:21 p.m.
Thomas Vander Stichele wrote:
Also, I had asked Matthias to symlink his RPMS.core to RPMS.os to be
in
line with fedora.us, though I've been told fedora.us might change
themselves from RPMS.os to RPMS.core; this allows people to choose to
get Fedora Core RPMS from either freshrpms or fedora.us (Since at work
we have a freshrpms local mirror, I'm forced to using that one :))
The decision of "RPMS.os" rather than "RPMS.core" was based upon:
1) fedora.us is not permanent, so our tree will disappear in the future
when the merger is complete.
2) We needed to launch the tree quickly when the time came, so for
simplicity we copied the identical structure that we used for RH8 and RH9.
I haven't heard any discussion about moving to RPMS.core but I am
certainly open to the idea. We would need to discuss ways of making a
smooth transition for all clients though. Panu's upcoming apt requires
reconfiguration of the client with his interactive mirror choosing
program, so perhaps that would be an opportune time to make the switch.
https://bugzilla.fedora.us/show_bug.cgi?id=1028
apt in fedora.us QA, HELP US TEST!
Warren
9:11 a.m.
Thomas Vander Stichele wrote :
The upcoming 0.4.3 release of mach will finally have Fedora Core 1
building support. It will also have n/v/r parsing based on the build
options (since, for example, Matthias Saou used some variables to
construct the Source tags).
I'm pretty sure I'm not the only one doing "flexible and sensible" stuff
in
the spec headers. Call that "funky" if you prefer, though :-)
There was support added to CVS by some others. I changed some
things
though, one of which is the basename for the distribution, which is why
I'm mailing. I've changed it to fedoracore-1-i386. Compare this to
(for rh9) redhat-9-i386.
I don't have any strong objections to "fedoracore-1-i386", but another
suggestions would be "fedora-1-i386-core" with the others called
"fedora-1-i386-extras", "fedora-1-i386-freshrpms", etc. which would
all
inherit core, as that is what "Core" is all about, it's the base set of
packages on which all the rest must rely, so it can get pretty implicit
IMHO.
Also, I had asked Matthias to symlink his RPMS.core to RPMS.os to be
in
line with fedora.us, though I've been told fedora.us might change
themselves from RPMS.os to RPMS.core; this allows people to choose to
get Fedora Core RPMS from either freshrpms or fedora.us (Since at work
we have a freshrpms local mirror, I'm forced to using that one :))
Well, I went for "core" as I felt it would be more consistent with all the
other bits and pieces that were to follow like "freshrpms", "extras",
"alternatives". The ones I'm not really satisfied with are
"updates" (as
they concern only "core") and "tupdates", the testing update. This is
mainly as I don't know if all other additional modules will be released
sets (like "powertools" were, with updates later on) or moving targets
(like most add-on repositories including freshrpms currently are, where
there are no separate updates, but where the main set get constantly
updated instead). I'd need to gather more information, see it discussed
here or just wait'n see I guess.
Since the actual distro released is Fedora Core 1, however, and
I'm
assuming there might be releases of other sets (say, Fedora Freeworld 1)
which might have another base, I wanted to make it explicit that this is
fedoracore and not fedora.
Do you mean that when referring to "Fedora", it would be the whole addition
of all available modules, including core? I guess it does make sense, as
"Fedora" alone already has it's short history of confusion, and that
it'll
take some consistency in the chosen direction in order to change that.
I could be persuaded to change this before the release, but I want
to
make sure people understand why I chose this for now and that I don't
intend to change it anymore after the release...
Well, probably as the n°1 annoying bug reporter for mach you've had so far,
I think I'd prefer "fedora-1-i386-core", eventually with an alias of
"f1c"
or "fc1" instead of "fedoracore-1-i386". Seems it would make more
sense for
the other modules, as they wouldn't contain the irrelevant (well, ok,
unuseful) "core" information in their name if they were then
"fedora-1-i386-freshrpms" instead of "fedoracore-1-i386-freshrpms".
Minor issue, cosmetic nonsense, being picky... whatever :-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2129.nptl
Load : 1.00 0.90 0.83
7453
days inactive
7454
days old
2 comments
3 participants
participants (3)
-
Matthias Saou -
Thomas Vander Stichele -
Warren Togami