Discussion:
[pacman-dev] debug package repositories
(too old to reply)
Thomas Bächler
2013-04-15 08:59:30 UTC
Permalink
All,
With the inclusion of the debug option in pacman 4.1.0, I think it makes
sense to do something with this in the official repositories. I've
sifted through some bug reports asking for inclusion of the debug
symbols in a separate package or repository officially for testing
purposes. With [extra] and [community] approaching 1.5 and 2 megabytes
respectively, I think that adding debug symbols directly into these
repositories would be a bad idea as it would probably add ~50% to those
databases, and I've already seen some people complain about the sizes.
This doesn't belong to the pacman mailing list (I'm forwarding to
arch-dev-public and arch-general), but I'll summarize what will probably
happen: Separate debug repositories won't happen - we can't even put
split packages into different repositories, so it is unlikely that we'll
support separate debug repositories - and I don't see the need. Even if
the db sizes double, we are still way under 5MB per db, which is a
reasonable size considering our users' bandwidth nowadays.

Allan stated that he'll add a glibc-debug package to core, and it is
also likely that KDE will get debug packages in extra (they have been
requested a few times).

Some links:

https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024736.html
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024740.html
Allan McRae
2013-04-15 09:11:39 UTC
Permalink
Post by Thomas Bächler
All,
With the inclusion of the debug option in pacman 4.1.0, I think it makes
sense to do something with this in the official repositories. I've
sifted through some bug reports asking for inclusion of the debug
symbols in a separate package or repository officially for testing
purposes. With [extra] and [community] approaching 1.5 and 2 megabytes
respectively, I think that adding debug symbols directly into these
repositories would be a bad idea as it would probably add ~50% to those
databases, and I've already seen some people complain about the sizes.
This doesn't belong to the pacman mailing list (I'm forwarding to
arch-dev-public and arch-general), but I'll summarize what will probably
happen: Separate debug repositories won't happen - we can't even put
split packages into different repositories, so it is unlikely that we'll
support separate debug repositories - and I don't see the need. Even if
the db sizes double, we are still way under 5MB per db, which is a
reasonable size considering our users' bandwidth nowadays.
Allan stated that he'll add a glibc-debug package to core, and it is
also likely that KDE will get debug packages in extra (they have been
requested a few times).
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024736.html
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024740.html
DB size is not the only consideration. For example -Ss output will be
"polluted".

Allan
Lukas Jirkovsky
2013-04-15 09:46:22 UTC
Permalink
Post by Thomas Bächler
Separate debug repositories won't happen - we can't even put
split packages into different repositories
Fair enough.
Post by Thomas Bächler
Even if
the db sizes double, we are still way under 5MB per db, which is a
reasonable size considering our users' bandwidth nowadays.
It's not only the size of the database. I can see the problem with the
size of repositories if someone keeps a mirror to save bandwidth if
they have lots of computers, but they don't need debug packages.
Post by Thomas Bächler
DB size is not the only consideration. For example -Ss output will be
"polluted".
Maybe it could be filtered on the pacman side, ie. add some switch
that would enable/disable showing of -debug packages.

Lukas
Allan McRae
2013-04-15 09:52:00 UTC
Permalink
Post by Lukas Jirkovsky
Post by Thomas Bächler
Separate debug repositories won't happen - we can't even put
split packages into different repositories
Fair enough.
Post by Thomas Bächler
Even if
the db sizes double, we are still way under 5MB per db, which is a
reasonable size considering our users' bandwidth nowadays.
It's not only the size of the database. I can see the problem with the
size of repositories if someone keeps a mirror to save bandwidth if
they have lots of computers, but they don't need debug packages.
Post by Thomas Bächler
DB size is not the only consideration. For example -Ss output will be
"polluted".
Maybe it could be filtered on the pacman side, ie. add some switch
that would enable/disable showing of -debug packages.
Not keen on that...

The issues that prevent split packages going across repos are entirely
different to what is required to keep a separate debug package repo.

In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.

Allan
Rashif Ray Rahman
2013-04-15 13:50:17 UTC
Permalink
Post by Allan McRae
In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.
I personally think that is the only way to go about it. I wouldn't
want -debug packages to take up search output, but I'd want them to
exist somewhere accessible.

An immediate possibility is to simply duplicate buildscripts to the
debug repos and push only debug packages there.

Of course, that'd be a manual process, and stuff won't be in
sync/integrated, but it does mean that it's not anything impossible
given our current packaging infrastructure.


--
GPG/PGP ID: C0711BF1
Tom Gundersen
2013-04-15 14:00:14 UTC
Permalink
Post by Rashif Ray Rahman
Post by Allan McRae
In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.
I personally think that is the only way to go about it. I wouldn't
want -debug packages to take up search output, but I'd want them to
exist somewhere accessible.
Couldn't pacman be fixed to only show debug packages in search results when
you ask for it with a switch? Maybe something similar could be done for
language packages?
Post by Rashif Ray Rahman
An immediate possibility is to simply duplicate buildscripts to the
debug repos and push only debug packages there.
Of course, that'd be a manual process, and stuff won't be in
sync/integrated, but it does mean that it's not anything impossible
given our current packaging infrastructure.
--
GPG/PGP ID: C0711BF1
Lukas Jirkovsky
2013-04-15 14:53:47 UTC
Permalink
Post by Allan McRae
In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.
You have my full support when it comes to having debug packages in a
separate repository.
Post by Allan McRae
Couldn't pacman be fixed to only show debug packages in search results when
you ask for it with a switch? Maybe something similar could be done for
language packages?
A simple alias/wrapper using grep on the pacman output would work too ;-)
Tom Gundersen
2013-04-15 15:05:32 UTC
Permalink
Post by Lukas Jirkovsky
Post by Allan McRae
In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.
You have my full support when it comes to having debug packages in a
separate repository.
Post by Allan McRae
Couldn't pacman be fixed to only show debug packages in search results when
you ask for it with a switch? Maybe something similar could be done for
language packages?
A simple alias/wrapper using grep on the pacman output would work too ;-)
Yeah, so why make a separate repo? What's the problem with keeping
debug packages in the normal repos?

-t
Dan McGee
2013-04-15 15:19:02 UTC
Permalink
Post by Tom Gundersen
Post by Lukas Jirkovsky
Post by Allan McRae
In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.
You have my full support when it comes to having debug packages in a
separate repository.
Post by Allan McRae
Couldn't pacman be fixed to only show debug packages in search results when
you ask for it with a switch? Maybe something similar could be done for
language packages?
A simple alias/wrapper using grep on the pacman output would work too ;-)
Yeah, so why make a separate repo? What's the problem with keeping
debug packages in the normal repos?
Our database files are rather large at this point, and for those that
will never install debug packages, having to download extra stuff
every time we update even one package in the database starts to get a
bit crazy.

Adding PGP signatures to our databases made these files grow quite a
bit; I'd be hesitant to double the size of them again.

-Dan

$ ls -lh /var/lib/pacman/sync/
total 3.8M
-rw-r--r-- 1 root root 52K Apr 14 13:17 community-testing.db
-rw-r--r-- 1 root root 1.9M Apr 15 06:26 community.db
-rw-r--r-- 1 root root 106K Apr 15 05:15 core.db
-rw-r--r-- 1 root root 1.5M Apr 15 05:09 extra.db
-rw-r--r-- 1 root root 3.8K Apr 13 14:09 multilib-testing.db
-rw-r--r-- 1 root root 105K Apr 13 18:59 multilib.db
-rw-r--r-- 1 root root 126K Apr 15 06:37 testing.db
Dan McGee
2013-04-15 16:01:49 UTC
Permalink
Post by Dan McGee
Post by Tom Gundersen
Post by Lukas Jirkovsky
Post by Allan McRae
In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.
You have my full support when it comes to having debug packages in a
separate repository.
Post by Allan McRae
Couldn't pacman be fixed to only show debug packages in search results when
you ask for it with a switch? Maybe something similar could be done for
language packages?
A simple alias/wrapper using grep on the pacman output would work too ;-)
Yeah, so why make a separate repo? What's the problem with keeping
debug packages in the normal repos?
Our database files are rather large at this point, and for those that
will never install debug packages, having to download extra stuff
every time we update even one package in the database starts to get a
bit crazy.
Adding PGP signatures to our databases made these files grow quite a
bit; I'd be hesitant to double the size of them again.
-Dan
$ ls -lh /var/lib/pacman/sync/
total 3.8M
-rw-r--r-- 1 root root 52K Apr 14 13:17 community-testing.db
-rw-r--r-- 1 root root 1.9M Apr 15 06:26 community.db
-rw-r--r-- 1 root root 106K Apr 15 05:15 core.db
-rw-r--r-- 1 root root 1.5M Apr 15 05:09 extra.db
-rw-r--r-- 1 root root 3.8K Apr 13 14:09 multilib-testing.db
-rw-r--r-- 1 root root 105K Apr 13 18:59 multilib.db
-rw-r--r-- 1 root root 126K Apr 15 06:37 testing.db
Hi Dan,
Sorry for replying directly, but I cannot send to the arch-dev-public list.
I just thought there might be a hybrid solution to this problem, adding a -debug.db
database file for each repo, and "activate" it using a pacman.conf flag.
[testing]
DebugPkgs = Disabled # Or not defined
=
update and use only testing.db
[testing]
DebugPkgs = Enabled
=
update and use both testing.db and testing-debug.db
With my limited insight, this keeps the "real" packages and their debug
information in the "same" repository (which may or may not be easier to work
with during package building), while limiting the download-size to the non-debug
part of the repository, unless DebugPkgs - or whatever it would be called - has
been explicitly enabled.
The solution is not far from simply creating a testing-debug repository,
but I think it would feel more integrated.
It would also be significantly more work, require changes to pacman,
etc. I don't see much benefit over a seperate repo other than a
slightly less verbose pacman.conf setup.

-Dan

Andrea Scarpino
2013-04-15 09:57:50 UTC
Permalink
Post by Thomas Bächler
Allan stated that he'll add a glibc-debug package to core, and it is
also likely that KDE will get debug packages in extra (they have been
requested a few times).
I can confirm the rumors about KDE: I want to put the qt, kdelibs & co -debug
packages (at least).

I don't see the pacman output as an issue here. There is already a '-debug'
suffix in the package name and maybe we could add it in the description too
e.g. '(Debug)'.
--
Andrea
Arch Linux Developer
Allan McRae
2013-04-15 10:01:15 UTC
Permalink
Post by Andrea Scarpino
Post by Thomas Bächler
Allan stated that he'll add a glibc-debug package to core, and it is
also likely that KDE will get debug packages in extra (they have been
requested a few times).
I can confirm the rumors about KDE: I want to put the qt, kdelibs & co -debug
packages (at least).
I don't see the pacman output as an issue here. There is already a '-debug'
suffix in the package name and maybe we could add it in the description too
e.g. '(Debug)'.
FYI:

pkgdesc="Detached debugging symbols for $pkgname"
Loading...