On 3/5/19 10:31 AM, Fabiano Fidêncio wrote: > 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. > Hmm I haven't seen that 'sources' issue but I guess if centos folks say 'dont use vault.centos.org' then we should listen to them. > 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; > Makes sense to me - Cole _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
