Bug 177966

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Geez, it would help if I posted the correct link:
http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-3-2.fc3.src.rpm

The sha1sum from above is correct
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDzBfyKe7MLJjUbNMRAozGAJ0YK6x6WuepewHF+ffYNmmvy42i/wCcD05U
LENvcTwF0uvPUBNYQafVmxg=
=AgMb
-----END PGP SIGNATURE-----

Maybe the package should add the repo to /etc/sysconfig/rhn/sources so up2date
will continue working. I think it should contain the FL GPG key also.

Would it be going too far to install the GPG key?

Installing the GPG key is fine IMHO.

Adding to RHN sources is probably good for FC3.  We don't need to worry about it
after FC3 as up2date and the RHN icon no longer work as expected.

So, should we install the GPG key and point to it rather than the URL?  The URL
just seems to be easier.  Also, where would the best place to install the GPG
key be?  The newer FC releases use /etc/pki, but FC3 used /usr/share/...  I
would lean towards /etc/pki - but are there any thoughts on that?

For up2date: does the (same) repo file just need to be copied to
/etc/sysconfig/rhn/sources or does anything else need to happen?

hrm, when using yum cli and the repo file has a link to the key, is hte user
prompted to accept the key?  No rpm --import necessary?  (I'm a bit foggy on
that one)

For up2date I think thats all that is necessary.  I'd look at the existing
sources just to verify.

FC3 needs to have the rpm --import done. yum in FC4 does this automatically.

For up2date, sources is a file that must be edited, not a directory you can
place a file into.

Attached is an untested spec file to illustrate.

Created attachment 123405 [details]
untested spec file

Mark, I think your spec looks good.  I do wonder about having an RPM import the
GPG key, that's something I'd prefer to have the user do by hand.

If anyone has an FC3 box, it'd be great to get this tested.

I wonder if we shouldn't find a way to disable the regular update channels. As
for the key, well, didn't the RH keys get auto-installed?

I am a little confused about the capabilities of various versions of yum, so
I have a question.

I had thought that yum versions <2.2 could only use the header method of
retrieving package metadata, but yum versions >=2.2 used the repodata .xml
method.  If this is true, and since Fedora Core 3 initially came out with
yum-2.1.11, but was upgraded to yum-2.2.2 last August, that would imply that:
   * the initial FC3 yum-2.1.11 software used "headers" (only?), and 
   * the upgraded yum-2.2.2 used "repodata".

The yum.conf(5) manpages from these two versions tend to confirm this.
For the 'baseurl' option for these two versions:
  *  yum-2.1.11's manpage says, "baseurl
              must be a url to the directory where the yum repository's 'head-
              ers' directory lives."
  *  yum-2.2.2's manpage says, "baseurl
              Must be a URL to the directory where the yum repository's `repo-
              data' directory lives."

Looking at the man pages for both versions of FC3 yum, it *appears*
that the older yum-2.1.11 can be (or automatcially is?) configured to check
for *.repo files in "/etc/yum.repos.d".  So it looks like we're okay adding
'fedora-legacy.repo' to the /etc/yum.repos.d for either version.  

So basically, what I want to confirm with the experts is:  
  - What version of yum can use what metadata format?
  - Can yum-2.1.11 use "headers"?  "repodata"?   both?
  - How about yum-2.2.2?

And further, if a given version of yum is able to use both "headers" and
"repodata", is it built into that version of yum to prefer one over the other?

Thanks.        --David

So in the case of the config file, it doesn't make a difference.  Both headers
and repodata are in the same top level directory the config file would check.

If yum can handle both, and both are present, repodata is preferred.  I do
believe I may still need to add headers to the os/ dirs for FC3 to satisfy that
need, and I will after I double check that FC3's yum from origin could handle
repodata.

Jesse, I think the "headers" directory should be added either way since it will
allow an upgrade path for those coming from FC2 and below.

At any rate, it won't make a difference to this package, since the URL remains
the same.

David, to answer some of your questions from comment #10:
From a quick look through the yum-2.1.11 code, it looks like it already supports
the (newer) repodata format.  As to whether or not it can use the older
"headers", I'm not sure.
yum 2.2 and newer all use the repodata and not the older headers format.

Thanks, Jesse, Jeff, for your answers.

Marc, regarding comment #9:  Why would we want or need to disable the regular
update channels at this juncture?  If we need to do it, is it something we
need to do now, or something we could do down the road a bit?

Are we coming closer to a package that we all can agree upon?  Do we need to 
spin a new .src.rpm and a (noarch?,i386?).rpm, get the .src.rpm formally
approved and binaries out to updates-testing?  Or are we using a different
methodology for the testing/release of this package?

Do we need to advertize somewhere, once we have binary packages available,
that we need FC3 testers to test this out for us?  Do we need to create
some kind of dummy (test) package to put in FC3 updates to see if any
testers can download and install the dummy package using the yum, apt-get,
and/or up2date mechanisms?

Speaking of up2date and apt-get:  Do those mechanisms for FC3 use the
repodata or the headers package metadata?

Sorry for so many questions... but I think we need to keep moving on this...
This does seem to be a blocker for any new updates we put out for FC3, until
or unless we also write specific directions as to how our users can modify
their own yum config/ apt-get config/ up2date config files for the FC3
legacy repository...

Thanks in advance!   -David

Oh - yet another question...   Do we want to hardwire downloads.fedoralegcy.org
as *THE* server from which people will grab downloads?  Many, if not most,
people will not think about (or even know about?) reconfiguring this to use
a closer mirror to download their packages, once it's installed and working on
their systems ("If it ain't broke, don't fix it!")...  Is there some option we
may wish to consider building into the install process to give the user the
option of selecting a closer mirror when this package is installed?  Or do we
care at this juncture?  And/or would it break something?

Thanks again!

Ok, so now we've said on list that FC3 content is available through apt.  Does
that mean we need to add changes to this RPM package to help apt users point
to our repositories too?

Hi David, I think that we agreed in IRC that the apt-rpm data would be generated
in the repository, but we would not do any apt stuff in this RPM.  ie. we would
provide support for apt, but not "officially".

Thanks, Jeff, for clearing up my confusion.  That makes sense.  apt metadata 
is available, but we're not promoting its use, encouraging yum's use instead.
cf. <http://fedoraproject.org/wiki/Tools/Apt>

Did we decide in the IRC discussion yesterday who is going to build a test
package with a spec-file like the one Marc shared in comment 7?  It seemed
to me it was going to be either you, Jeff, or Marc; but I don't recall who.

Was it decided that, since Marc has a FC3 machine, that he would do the needed
testing of yum and up2date?  

Am trying to make sure the plan is understood and documented.  If we can 
make things so they are repeatable and understandable to everyone.  Having
some kind of software process in place, even if it is decided that we throw
it away later, helps us and helps other folks down the road who may inherit
our work.

Hi David, Marc said that he would build and test the package and then post it
here for review before pushing it to the legacy-utils repo.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are the packages. They seem to work fine on my test system.
If everyone is okay with them, I'll build them, sign them, and
put them in the utils directory.

ac41efbab8e5b90a826a17afd74d7d8f8d1851e5  legacy-yumconf-3-3.fc3.noarch.rpm
19b16df792b9bf50be10065362fb38e17ccc24e4  legacy-yumconf-3-3.fc3.src.rpm

http://www.infostrategique.com/linuxrpms/legacy/3/legacy-yumconf-3-3.fc3.noarch.rpm
http://www.infostrategique.com/linuxrpms/legacy/3/legacy-yumconf-3-3.fc3.src.rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD2qbcLMAs/0C4zNoRAqZ8AKCU6OWM+g1Wki4FXtyOUN3vT4fNqgCglG7G
nnmaDvzRwlCBmaIJ4WtP9r0=
=opTf
-----END PGP SIGNATURE-----

Marc, it looks good to me.  The only thing I would change is the summary and
description so that it mentions both yum and up2date (currently it just includes
yum).  Aside from that, it has my publish vote.

Looks good here too.  Just one thought.  Would it be good to put this into
the .spec, just to make it foolproof?

    Requires: fedora-release = 3

This way, the binary package will refuse to install if some users decided to
try to install in on, say, Fedora Core 1?

Hrm... good point.  Please do add that.  Then I think we're good to go, publish
away.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hope you don't mind, since I was already fiddling with it.  I went ahead and
made updated packages incorporating the suggestions by Jeff and me (comments
20 and 21).  Here they are.

2702a21ca8956a0043d8b31cb4aa54374d669939  legacy-yumconf-3-4.fc3.src.rpm
c16dc375d79ebe6a475de324f5e54e85584a6236  legacy-yumconf-3-4.fc3.noarch.rpm

http://fedoralegacy.org/contrib/legacy-yumconf/legacy-yumconf-3-4.fc3.src.rpm
http://fedoralegacy.org/contrib/legacy-yumconf/legacy-yumconf-3-4.fc3.noarch.rpm

You may want to test to make sure they still work right, Marc.  Thanks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFD3s0Vxou1V/j9XZwRAgx/AKDHrIWSsUr5XCso2dotVLzbU2P37QCfWfus
74jV8/VMCW9wyDu09SjtVME=
=6sSX
-----END PGP SIGNATURE-----

David, your rpm looks good to me.

*ping*

Are we ready to push this out then?

I don't have FC3, so I can't test it...  But I might be able to ask someone
who has FC3 to see if they might test it for us, if we feel it needs further
testing....

They work on my FC3 machine.

They're good to go.

Packages were released.