Re: [arch-general] [pacman-dev] debug package repositories
Am 13.04.2013 17:55, schrieb William Giokas:
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.ht... https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024740.ht...
On 15/04/13 18:59, Thomas Bächler wrote:
Am 13.04.2013 17:55, schrieb William Giokas:
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.ht... https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024740.ht...
DB size is not the only consideration. For example -Ss output will be "polluted". Allan
On 15 April 2013 09:59, Thomas Bächler <thomas@archlinux.org> wrote:
Separate debug repositories won't happen - we can't even put split packages into different repositories
Fair enough.
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. On 15 April 2013 10:11, Allan McRae <allan@archlinux.org> wrote:
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
On 15/04/13 19:46, Lukas Jirkovsky wrote:
On 15 April 2013 09:59, Thomas Bächler <thomas@archlinux.org> wrote:
Separate debug repositories won't happen - we can't even put split packages into different repositories
Fair enough.
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.
On 15 April 2013 10:11, Allan McRae <allan@archlinux.org> wrote:
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
On 15 April 2013 17:52, Allan McRae <allan@archlinux.org> wrote:
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
On 15 April 2013 10:52, Allan McRae <allan@archlinux.org> wrote:
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. On 15 April 2013 15:00, Tom Gundersen <teg@jklm.no> wrote:
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 ;-)
On Mon, Apr 15, 2013 at 4:53 PM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
On 15 April 2013 10:52, Allan McRae <allan@archlinux.org> wrote:
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.
On 15 April 2013 15:00, Tom Gundersen <teg@jklm.no> wrote:
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
On Mon, Apr 15, 2013 at 07:52:00PM +1000, Allan McRae wrote:
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.
If there is any work that I can do to move this along, let me know here or on IRC. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
Am 15.04.2013 17:40, schrieb William Giokas:
On Mon, Apr 15, 2013 at 07:52:00PM +1000, Allan McRae wrote:
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.
If there is any work that I can do to move this along, let me know here or on IRC.
Thanks,
Allan already said he'll do the work (probably some work in devtools and dbscripts), so I don't particularly care anymore - once the work is done, I can live with a separate debug repo.
participants (6)
-
Allan McRae
-
Lukas Jirkovsky
-
Rashif Ray Rahman
-
Thomas Bächler
-
Tom Gundersen
-
William Giokas