On Tue, 2019-03-05 at 09:33 -0500, Cole Robinson wrote: > On 3/5/19 7:52 AM, Fabiano Fidêncio wrote: > > On Tue, 2019-03-05 at 13:48 +0100, Fabiano Fidêncio wrote: > > > On Tue, 2019-03-05 at 13:22 +0100, Fabiano Fidêncio wrote: > > > > On Fri, 2019-03-01 at 18:41 -0500, Cole Robinson wrote: > > > > > This series adds: > > > > > > > > > > * centos5 entries > > > > > * centos6 <tree> data > > > > > * scientificlinux 5.X > > > > > * scientificlinux 6.X > > > > > * scientificlinux 7.X > > > > > > > > > > No iso data is added, just URLs. I'm trying to get osinfo-db > > > > > to > > > > > have > > > > > all the treeinfo coverage that virt-install has. > > > > > > > > Cole, in the general the series look good (apart from one > > > > change > > > > that > > > > has to be for "Add scientificlinux-7.X". > > > > > > > > There's one thing that I'm interested to know, though: > > > > - Is x.y considered EOL whenever x.(y+1) is released? I mean, > > > > will > > > > 7.6 > > > > be considered EOL whenever 7.7 is released? If so, we'd also > > > > have > > > > to > > > > add the EOL to the 7.x entries. > > > > > > > > Anyways, for patches #1 to #5: > > > > Reviewed-by: Fabiano Fidêncio <fidencio@xxxxxxxxxx> > > > > > > Actually, let me take my "Reviewed-by" back. > > > Please, take a look at 5cac22bc68[0]. > > > > > > There, the commit message states: > > > centos: Remove URLs pointing to vault.centos.org > > > > > > As vault.centos.org doesn't keep any ISO anymore, let's just > > > remove > > > them from our db. > > > > > > Along with the URLs removal, let's remove together the tree's as > > > those > > > can't be accessed without a valid URL. > > > > > > Removing all the vault.centos.org URLs matches with the > > > recommendation > > > given by CentOS folks in #centos-devel: > > > "so in short, if some program links to vault, it's most likely > > > not a > > > good idea and may not even work" > > > > > > [0]: > > > https://gitlab.com/libosinfo/osinfo-db/commit/5cac22bc6852d56988ff4be090551c5ec2f3f108 > > > > > > So, I guess the path to take is to drop #1 and #3. > > > > Errr, dropping the URLs from #1 and #3, but keeping the > > tree/treeinfo. > > > > ACK from me, though what was centos reasoning for not pointing to > vault.centos.org tree URLs? Those have been stable for years in my > experience. I can understand if they don't want those advertised but > it's unclear why the comment suggests it might not work So, the whole conversation I had on #centos-devel was more about link to their medias than the tree itself, but let me try to summarise everything there: I've contacted #centos-devel because the EOL medias are always removed from vault, in a way that the links would automatically redirect to http://vault.centos.org/notonvault.html ... This is expected as a CentOS release becomes unsupported shortly after a new release comes out. The trees follow pretty much the same process as the one followed by the ISOs. So, for instance, while we have a valid tree for 6.10 ( http://mirror.centos.org/centos/6.10/os/x86_64), the tree for 6.9 is not valid anymore. Trying to access http://mirror.centos.org/centos/6.9/os/x86_64/ you'd get a 404 and http://mirror.centos.org/centos/6.9/ has one single file mentioning that the system has reached its EOL: http://mirror.centos.org/centos/6.9/readme Apart from that, I've also faced some issues where we'd have the tree but only with the sources but not with the packages. When I asked about that, the aswer that I got was that apps should not be relying on vault. One thing that we can do is to: - Always add the URL for the current supported release; - Remove the URL as soon as the new release is done; What do you think? Best Regards, -- Fabiano Fidêncio _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
