#6081: please keep releases.txt up-to-date -----------------------------+------------------------ Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ In order to implement a graphical fedup frontend, we need to have a way to find out when new releases become available. preupgrade had this, with http://mirrors.fedoraproject.org/releases.txt. We'd like to keep using the same mechanism. Of the fields mentioned that are listed in the files documentation, only version and installmirrorlist are really important for us, although eol-date may be useful as well.
#6081: please keep releases.txt up-to-date ------------------------------+----------------------- Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Final | Component: koji Resolution: | Keywords: Blocked By: | Blocking: ------------------------------+-----------------------
Comment (by kevin):
One of the very nice things about preupgrade going away was that we no longer had to mess with this manually updated file. ;(
One possiblity (although it would still require some changes) is to look at the metalink mirrormanager has for the install images.
For example, fedup currently looks at:
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora- install-21&arch=x86_64
(or whatever arch) for a list of mirrors to get the install images from.
In the last cycle we updated that before 21 was released, but perhaps we could look at not doing that until it's out and you could use the existance of those mirrors as a key. Or we could update it for Alpha/Beta, but you could see the Alpha/Beta in the links to know it's not final?
I'd really prefer if we come up with a way to do this that avoids a manually updated file if we can at all.
#6081: please keep releases.txt up-to-date ------------------------------+----------------------- Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Final | Component: koji Resolution: | Keywords: Blocked By: | Blocking: ------------------------------+-----------------------
Comment (by mclasen):
I'm fine with any mechanism, as long as it is reliable and avoids premature notification - just looking for the repository with the right name on the mirrors has the downside that we a) need to hardcode details about the directory layout and b) it might show up before the release is officially out (as you say, that happened for f21).
#6081: please keep releases.txt up-to-date ------------------------------+----------------------- Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Final | Component: koji Resolution: | Keywords: Blocked By: | Blocking: ------------------------------+-----------------------
Comment (by pbrobinson):
What about the .treeinfo file that is used by fedup as part of the upgrade process? There's an example here
https://dl.fedoraproject.org/pub/fedora/linux/releases/21/Server/x86_64/os/....
#6081: please keep releases.txt up-to-date ------------------------------+----------------------- Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Final | Component: koji Resolution: | Keywords: Blocked By: | Blocking: ------------------------------+-----------------------
Comment (by pingou):
If the URL are really stable, maybe relying on pkgdb could be an option?
Collection that are 'Under development' are the non-released branches, 'Active' are the current one and the old ones are 'EOL' and pkgdb should have the required information about the name of the collection for yum, no?
https://admin.fedoraproject.org/pkgdb/api/#list_collections
#6081: please keep releases.txt up-to-date ------------------------------+----------------------- Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: koji Resolution: | Keywords: next Blocked By: | Blocking: ------------------------------+----------------------- Changes (by pfrields):
* keywords: => next * cc: pfrields (added) * milestone: Fedora 21 Final => Fedora 22 Final
Comment:
In next-gen compose tools, some dependency ordering and fedmsg tie-in may be possible to kicks off correct tasks at the right time. So for instance, if there's an approved compose, and that gets marked in some way, it could trigger the creation of such a file too. threebean and I had tossed around an idea of doing this with some sort of systemd/container based solution so it doesn't have to become a human's job to figure out and debug the ordering constantly.
I propose we use a keyword like ''next'' for ideas that should be covered in such tools. I'm not saying those are infinitely far off, either. I'm having some preliminary discussion with dgilmore & pbrobinson on how the Fedora Engineering team can pitch in to help with these tools and the process by which they're developed and tested for rel-eng use in production.
I'm going to go ahead and tag this with keyword ''next'' with the understanding that other people may have better (or even just more immediate) ideas, and my intent is not to block those ideas. This note is more to provide a reference point to help gather inputs.
#6081: please keep releases.txt up-to-date ------------------------------+----------------------- Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: koji Resolution: | Keywords: next Blocked By: | Blocking: ------------------------------+-----------------------
Comment (by kevin):
So, can the requestors here see if the pkgdb api in comment 4 will meet their needs?
Thats best from my point of view as manually updating a file is prone to failure and means there's another place instead of getting all that info from one place.
#6081: please keep releases.txt up-to-date ------------------------------+----------------------- Reporter: mclasen | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: koji Resolution: | Keywords: next Blocked By: | Blocking: ------------------------------+-----------------------
Comment (by mclasen):
Replying to [comment:6 kevin]:
So, can the requestors here see if the pkgdb api in comment 4 will meet
their needs?
Thats best from my point of view as manually updating a file is prone to
failure and means there's another place instead of getting all that info from one place.
Richard and Kalev both said that this would be fine, gnome-software can easily use this as a datasource.
rel-eng@lists.fedoraproject.org
-
Fedora Release Engineering