DevHeads.net

debuginfo.centos.org status

Hello folks,

I have few remarks about <a href="http://debuginfo.centos.org" title="http://debuginfo.centos.org">http://debuginfo.centos.org</a> as an user.

Lately our debug tools are depending on few debuginfo packages so we
depend on them in our production environment.

The debuginfo server is structured as following :
.
├── 7
│ ├── i386
│ │ └── repodata
│ └── x86_64
│ └── repodata
└── centos
├── 6
│ └── sclo
└── 7
├── cloud
├── sclo
├── storage
└── virt

1/ It seems that the experimental kernel debuginfo are copied in the
same directory as the os/updates/extras which confuse a bit users
(/7/x86_64/)

e.g :
<a href="http://debuginfo.centos.org/7/x86_64/kernel-debuginfo-4.9.75-204.el7.centos.x86_64.rpm" title="http://debuginfo.centos.org/7/x86_64/kernel-debuginfo-4.9.75-204.el7.centos.x86_64.rpm">http://debuginfo.centos.org/7/x86_64/kernel-debuginfo-4.9.75-204.el7.cen...</a>

Is there an official way to enable a repo to use these experimental
kernel
(<a href="http://mirror.centos.org/altarch/7/experimental/x86_64/Packages/" title="http://mirror.centos.org/altarch/7/experimental/x86_64/Packages/">http://mirror.centos.org/altarch/7/experimental/x86_64/Packages/</a>) ? In
my opinion the debuginfo packages should be in a separate repo too.
Could we move them to a better place ? under /altarch as the main
packages on mirror ?

2/ Do we want to reorganize the debuginfo server ?

I would favor a tree where we can have debuginfo separated per repos as
we do for sigs :

.
├── 7
│ ├── i386
│ │ └── os
│ │ └── updates
│ │ └── extras
│ │ └── etc...
│ └── x86_64
│ │ └── os
│ │ └── updates
│ │ └── extras
│ │ └── etc...

What do you think ?

Comments

Re: debuginfo.centos.org status

By Johnny Hughes at 03/20/2018 - 06:13

On 03/12/2018 04:43 AM, Thomas Oulevey wrote:
All the debuginfo files were designed to be in a flat structure from the
beginning.

I would have to change all our scripts to change how this is done.

I can do that and it would not be that hard (it would take some time,
but it can certainly be done).

However, how does that impact our millions of users who currently use
the system and their scripting, etc.

Right now, people only have to go one place and use their current ENVR
in the call and they can get anything. They would have to change their
scripting to look in all the different places if we shift. I am unsure
how that might impact people.

Thanks,
Johnny Hughes