gridcf / gct-docs

Grid Community Toolkit documentation
http://gridcf.org/gct-docs/
1 stars 4 forks source link

outdated binary package section #14

Closed msalle closed 2 years ago

msalle commented 5 years ago

As reported on the discuss mailing list: The section https://github.com/gridcf/gct-docs/blob/gh-pages/6.2/admin/quickstart/prereq_frag.adoc is heavily out-of-date, still referring to globus.org and local repositories. Additionally, also the related https://github.com/gridcf/gct-docs/blob/gh-pages/6.2/admin/install/install_frag.adoc contains outdated instructions.

fscheiner commented 5 years ago

Maybe best would be to try the quickstart and admin guides on the "supported" OSes and OS versions like:

...and update them accordingly (incl. removal of stuff currently not built/unsupported, like MacOS/Windows packages).

That would need some time and effort, therefore it might be better to spread the load. I'd volunteer to test on Debian and Ubuntu as I haven't used the toolkit there since ages.

msalle commented 5 years ago

Not sure whether this makes sense at this point. We have EPEL and Debian (supported) packages and those come from the respective standard repos. The main problem (in my opinion) is that we refer to custom repos which don't exist such as in:

In GCT 6, there are three Grid Community Toolkit package repositories: Stable, Testing, and Unstable.

My preference would be to remove (comment out in the adoc?) the obsolete stuff. If we at some point decide to re-enable our own repos we can then resurrect those bits.

matyasselmeci commented 4 years ago

We should at least say that the packages should be downloaded from the standard repos. I can take care of that -- probably the best to fork off a new issue and assign that to myself.

fscheiner commented 4 years ago

@matyasselmeci @ellert @msalle The documentation at https://gridcf.org/gct-docs/latest/admin/quickstart/index.html#q-toolkit refers to package groups or virtual packages (i.e. globus-gridftp, `globus-data-management-server, etc. which install/depend on multiple (related) packages) which aren't available in EPEL/Fedora and I also didn't create them for SUSE. But we still have RPM spec files for these packages in our GCT repo.

Actually those are quite helpful if you (as new user) don't know what you need exactly for a GridFTP server or client, e.g. nobody expects globus-url-copy to be located in the package globus-gass-copy-progs (although you can find that out using something like yum whatprovides [...]) but globus-data-management-client at least sounds like related (maybe a lttle far fetched ;-)).

So why don't we create those packages?

msalle commented 4 years ago

That sounds indeed like a good idea.

msalle commented 2 years ago

Note, the pages to be fixed are now on the adoc branch: