I've been spining my head for 2 hours now trying to understand how yum goes through a repo cause i'm getting a very strange behavior.
Some background:
Local epel-7 repo on repo server
repo was created using reposync (reposync, createrepo, repomanage)
can see the repo find using http://local.reposerver/epel-7-x86_64/
I can also see the files using a shell on repo server
client is configured and has network access to repo
Epel-7 repository structure is a little different than Epel-6 structure. It looks like this:
tree -d
.
├── 0
├── 2
├── 3
├── a
├── b
├── c
├── d
├── e
├── f
├── g
├── h
├── i
├── j
├── k
├── l
├── m
├── n
├── o
├── p
├── q
├── r
├── repodata
├── s
├── t
├── u
├── v
├── w
├── x
├── y
└── z
30 directories
With all the packages under their letters/numbers
I'm saying this because the heart of my problem is that when i do a:
yum --disablerepo="*" --enablerepo="epel-7" list available
I get all the package allthrough the L directory....everything after is ... not there... lost... or what ever which is very strange.
I've tried clearing everything:
yum clean all
I've tried deleting the repodata on the repo server and recreate it... nothing works.
That is why i would very much like to know the internals of the yum search command... which file/db/ it calls so i can find which one is corrupted/broken.
Could it be a cache on the http server side?
Thanks for your help!
Related
I am trying to create a debian package for a postgreSQL extension Apache-age release 1.1.1 and created the directory structure using dh_make command.
The directory structure is as follows:
age-1.1.1 (project root)
├── debian
│ ├── changelog
│ ├── compat
│ ├── control
│ ├── docs
│ ├── examples
│ ├── links
│ ├── manpages
│ ├── menu
│ ├── postinst
│ ├── postrm
│ ├── preinst
│ ├── prerm
│ ├── rules
│ ├── source
│ └── watch
├── src
└── Makefile
The dpkg-buildpackage -b when run from project-root folder it looks for debian folder, then reads the rule file, then reads the Makefile located in the project root to build the package.
I want to change the directory structure to the following:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ └──
├── src
├── LICENSE
├── README.md
├── Makefile
└── ...
I want to change the directory structure so that the dpkg-buildpackage -b command can be run from the packaging folder and it should build the package.
Inside your Makefile
Modify the install paths accordingly. It should point to your packaging/debian/* where * is the filename.
This way the Makefile can point to the correct file path target inside the new folder structure.
I'm not sure if this is the best way to do this but it's working for me:
Here are the steps:
First run the dh_make_pgxs command from the project root directory.
Create a packaging directory in the project root and move the debian directory created in step 1 to this directory along with the Makefile, age.control and the age--1.1.1.sql.
Your file structure should look like this:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ ├── age--1.1.1.sql
│ ├── age.control
│ ├── Makefile
│ └── ...
├── src
├── LICENSE
├── README.md
└── ...
Change the file paths in the Makefile like:
src/backend/age.o should be ../src/backend/age.o.
./tools/ should be ./../tools/.
and so on.
Now you can simply run the dpkg-buildpackage -b command from the packaging directory to build the debian package.
Note: In step 1 we are running dh_make_pgxs in the project root first, this is to make sure that the project name in the control files and the version in the changelog file are correct. In this case the name/source in control, control.in & changelog files should be apache-age and the version number in changelog file should be 1.1.1-1.
Alternatively, you can run the command from the packaging directory and manually change the name and version in the control and changelog files.
During experiments with Yocto's Advanced Kernel Metadata I got into a situation where I would like to have the .scc, .patch and .cfg files organized into a directory structure as mentioned in the syntax section, and to keep that structure in all the layers (consider 2 layers here - meta-main_layer and meta-bsp_layer):
meta-main_layer
└── recipes-kernel
└── linux
└── linux-yocto.bb
└── linux-yocto
├── cfg
│ ├── main_frag_1.cfg
│ └── main_frag_1.scc
├── features
│ ├── main_feature_1.cfg
│ ├── main_feature_1.patch
│ └── main_feature_1.scc
└── patches
├── main_patch_1.patch
└── main_patch_1.scc
meta-bsp_layer
└── recipes-kernel
└── linux
└── linux-yocto.bbappend
└── linux-yocto
├── bsp
│ └── bsp_definition.scc
├── cfg
│ ├── bsp_frag_1.cfg
│ └── bsp_frag_1.scc
├── features
│ ├── bsp_feature_1.cfg
│ ├── bsp_feature_1.patch
│ └── bsp_feature_1.scc
└── patches
├── bsp_patch_1.patch
└── bsp_patch_1.scc
meta-main_layer/recipes-kernel/linux/linux-yocto.bb contains:
FILESEXTRAPATHS_prepend := "${THISDIR}:"
...
SRC_URI = "file://linux-yocto;type=kmeta \
"
Edit:
And meta-bsp_layer/recipes-kernel/linux/linux-yocto.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}:"
...
SRC_URI += " file://linux-yocto;type=kmeta \
"
... end of edit
This means that after parsing the recipes, the SRC_URI will contain file://linux-yocto;type=kmeta twice, and FILESEXTRAPATHS=meta-bsp_layer/recipes-kernel/linux:meta-main_layer/recipes-kernel/linux:. The way I understand it, the do_unpack() task goes through the files in SRC_URI and for each of them, it searches FILESEXTRAPATHS for that file, and it takes the first one it finds. That means that in my case, only the files from meta-bsp_layer are taken, as its path is the first in FILESEXTRAPATHS, and the files from the meta-main_layer are ignored.
What I would like to achieve is that instead of taking the files from only the first path found in FILESEXTRAPATHS, do_unpack() would go through all of the paths in FILESEXTRAPATHS and merge the directories of the same name (cfg, features and patches) from both layers. Without that, I don't see any big benefits of using the Advanced Kernel Metadata mechanism. Could anyone advise how to get this done?
PS: I'm using Yocto Zeus.
I am trying to elegantly setup my Sphinx to work with GitHub pages. I want to maintain separate build and source directories (seen in the directory tree below).
repository
├── docs
│ ├── build
│ │ └── index.html
│ ├── Makefile
│ └── source
| | ...
|
├── README.md
└── src
| ...
I have the GitHub repository set to look for the index.html in /docs/.
Question: Is there a way to place a symbolic link or an index.html in the root of /docs/ that points to /docs/build/index.html?
I got this structure:
├── root
│ ├── app A
│ ├── app B
│ ├── app C
The root folder is initialized as git folder so I can easily push the whole project. Now I am wondering where to place the kubernetes yaml files.
My idea would be something like this:
├── root
│ ├── app A
│ ├── app B
│ ├── app C
│ ├── kubernetes.conf.d
├── appA.yaml
Question: is there is a common location to place the config files for kubernetes?
This is completely subjective and you should do whatever works for you. My preference, however, is:
# Each application has
- opt
- kubernetes
- deployment.yaml
- helm
- values.yaml
I like using ./opt, as it is familiar to most with Unix experience.
I have downloaded a rpm in my ansible-playbook:
(djangoenv)~/P/c/apache-installer ❯❯❯ tree .
.
├── defaults
│ └── main.yml
├── files
│ ├── apache2latest.tar
│ ├── httpd_final.conf
│ ├── httpd_temp.conf
│ └── sshpass-1.05-9.1.i686.rpm
├── handlers
│ └── main.yml
├── hosts
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
My question is why can't I just install it using:
- yum: name=files/sshpass-1.05-9.1.i686.rpm
? It complains that files/sshpass-1.05-9.1.i686.rpm is not found in the system. Now I am doing it in two steps:
- copy: src=files/sshpass-1.05-9.1.i686.rpm dest=/tmp/sshpass-1.05-9.1.i686.rpm force=no
- yum: name=/tmp/sshpass-1.05-9.1.i686.rpm state=present
No, there is no simple way around coping the package to the remote host before installing. Ansible yum module expects a local file when you define a file in the name parameter.
IMHO it is not a good idea to keep packages inside the Ansible code base. Because they are binary and not exactly part of the actual Ansible code. It would be cleaner to setup a private repository and store those files there. That is the only way around coping a package in this situation I'm aware of.