Notes from the Technical Discussion Meeting 31/8/2016

Present: neilb, ascobie, roger, iainr, idurkacz, cc

Were were considering whether the guidelines on https://www.wiki.ed.ac.uk/display/LCFG/RPMRepositoriesProposal#RPMRepositoriesProposal-naming are still appropriate, and in what cases should the local tagging/naming of RPMs apply.

From the above:

Local RPM Naming Policy

We need a local RPM naming policy to ensure uniqueness of filenames in the shared repository, and identify where the RPM was packaged. For reference, in general the form of an RPM file name is

$name-$version-$release.$arch.rpm

$release is where we indicate the local provenance of a package. Release fields are made up of a number of components, where a component is $localrelease.$localid. Components may be concatenated with periods as $component1.$component2.$component3 and so on, to produce a complete release field, with the most recent component being at the end.

The bit we were mostly discussing was when does "$localrelease.$localid" apply (LL for short).

LL is not just a record of changes, but also a note of the environment that a package was built in. eg possibly different libraries, paths, etc even when built from the same SRPM.

Fedora tags all RPMs with the build environment, eg f24 f25

Ian asked, What is the problem we are trying to solve? I don't think it was particularly well discussed, but it is so you can be confident that at you get the RPM you are expecting when you ask for it to be installed on your machine.

Not discussed at the TDM, but I think the penny finally dropped for me ...

updaterpms has various locations defined in updaterpms.rpmpath in which to look for the RPM foo-1-2. It will use the first matching one it finds. Those locations include:

http://cache.pkgs.inf.ed.ac.uk/sites/sl/7.2/x86_64/os/Packages/lcfg
http://cache.pkgs.inf.ed.ac.uk/sites/sl/7.2/x86_64/updates/security/lcfg
http://cache.pkgs.inf.ed.ac.uk/sites/epel/7/x86_64/lcfg
http://cache.pkgs.inf.ed.ac.uk/rpms/os/el7/x86_64/lcfg
http://cache.pkgs.inf.ed.ac.uk/rpms/os/el7/x86_64/uoe
http://cache.pkgs.inf.ed.ac.uk/sites/is/world/el7/rpms
http://cache.pkgs.inf.ed.ac.uk/sites/is/uoe/el7/rpms

foo-1-2 will come from the first location that contains that RPM. As you can see a couple of IS repositories/buckets are also included. So if we (Informatics) and EE both build foo-1-2 from an SRPM or cpan2spec, and we submit ours to "uoe" and EE to "is/uoe". Then a profile asking for foo-1-2 will get which ever one happens to be first in the rpmpath list. Which may be an issue if the INF and EE environment used to build foo are different.

So to make sure each gets the version the are expecting, then they should be submitted with the releases foo-1-2.1.inf and foo-1-2.1.ee respectively, and the profiles updated to ask explicitly for the .inf or .ee version.

Obviously if Inf are thinking about building foo-1-2, but spot that there already exists foo-1-2.1.ee, then they could just try installing that, if it works just continue to use it, and not bother building their own version.

Are the other schools sticking to the guidelines?

  • Those asked at the LCFG deployers meeting - Yes.

We should have an RPM packaging supremo, who can adjudicate on questions asked.

Is the world bucket, actually world accessible?

  • Answer - ?

Where do support RPMs for a component go, lcfg or world?

  • If not part of the base OS, then in lcfg. (Check)

Initially some thought there was the conflicting information on the naming scheme, possibly to do with concatenating local. However we couldn't find it at the time.

  • Is there contradictory guidance? If so, locate and correct.

At the meeting there was no real consensus on the use of LL for SRPMs you just download (or via cpan2spec) and build (no changes what-so-ever). Neil said he'd goto LCFG deployers meeting tomorrow to see what others do regarding this.

  • At the meeting, it was clear everyone does locally tag RPMs they've built.

Iain thinks we should always add 1.inf, even if all we've done is just build. No code changes. Any code changes, or spec changes, WOULD require a 1.inf.

Following the Fedora guidelines where possible. - iainr

Gitlab type software

We didn't really discuss this. We'll save it for another day, but some things were muttered.

  • container - docker
  • drupal
  • wordpress
  • nx
  • some other package that EE/Maths/Physics(?) were using

-- NeilBrown - 02 Sep 2016

Topic revision: r1 - 02 Sep 2016 - 11:01:11 - NeilBrown
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies