[arch-dev-public] Heimdal changes
Tonight I've been working on heimdal. I found out some things about this package: 1. It includes libeditline, a BSD port of libreadline. Nothing in the package uses this library, as heimdal is compiled with readline. The installed libreadline.* files are actually broken libraries, because they're missing the strlcopy symbols, which are only available on *BSD platforms, not in glibc. 2. We've been using patches from gentoo for a long while. The patches we included were introduced in some 0.7 version, and never reviewed in later versions. In the meanwhile, some don't apply or were replaced by newer patches. 3. Heimdal uses an internal snapshot of sqlite and links this one static inside the krb5 libraries. While this reduces dependencies, it has two problems: - security fixes in sqlite have to be tracked inside heimdal - static linking is evil because applications utilizing sqlite will end up with two copies of the sqlite library in memory I changed the PKGBUILD, added patches, added a dependency to sqlite3 and pushed it to testing. I also added -Wl,--as-needed to LDFLAGS to reduce link dependencies on sqlite3, as each and every binary links to it without these flags, while it's only used in the client libraries for the credentials cache. I would like to have some review on this, as it's a core package. This will also mean that sqlite3 has to be pulled from extra into core (or ssh and heimdal move to extra, as ssh is the only core package using heimdal, though I assume that's not a reasonable option).
The new heimdal package I created depends on sqlite3 now because I replaced the included static copy of sqlite inside heimdal with the dynamic linked system installed version. Sqlite3 is in extra, while heimdal is in core. At this moment only ssh in core depends on heimdal. Do we move heimdal and ssh out of core into extra, or do we move sqlite3 into core? Any opinions?
Jan de Groot wrote:
The new heimdal package I created depends on sqlite3 now because I replaced the included static copy of sqlite inside heimdal with the dynamic linked system installed version. Sqlite3 is in extra, while heimdal is in core. At this moment only ssh in core depends on heimdal. Do we move heimdal and ssh out of core into extra, or do we move sqlite3 into core? Any opinions?
Is ssh really needed for getting a system running and ready to install further packages (my definition of what should be in [core])? I really do not think it is needed so I am happy with this moving to [extra]. Allan
Allan McRae schrieb:
Is ssh really needed for getting a system running and ready to install further packages (my definition of what should be in [core])? I really do not think it is needed so I am happy with this moving to [extra].
Allan
IMO, ssh should really be in core! Why does it have to be compiled against heimdal?
On Fri, 2009-01-09 at 12:15 +0100, Thomas Bächler wrote:
Allan McRae schrieb:
Is ssh really needed for getting a system running and ready to install further packages (my definition of what should be in [core])? I really do not think it is needed so I am happy with this moving to [extra].
Allan
IMO, ssh should really be in core! Why does it have to be compiled against heimdal?
On Fri, Jan 9, 2009 at 5:15 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Allan McRae schrieb:
Is ssh really needed for getting a system running and ready to install further packages (my definition of what should be in [core])? I really do not think it is needed so I am happy with this moving to [extra].
Allan
IMO, ssh should really be in core! Why does it have to be compiled against heimdal?
SSH not being in [core] seems weird as heck to me... -Dan
2009/1/9 Allan McRae <allan@archlinux.org>:
Is ssh really needed for getting a system running and ready to install further packages (my definition of what should be in [core])? I really do not think it is needed so I am happy with this moving to [extra].
sshd is if you're doing a remote install. I wouldn't be surprised if there are other packages in core that could utilize sqlite if it was there. Its pretty popular for embedding in other apps. Dusty
On Fri, Jan 9, 2009 at 7:03 AM, Allan McRae <allan@archlinux.org> wrote:
Is ssh really needed for getting a system running and ready to install further packages (my definition of what should be in [core])? I really do not think it is needed so I am happy with this moving to [extra].
Allan
There was one time that a moron of a reviewer said Arch Linux sucks, because ssh was not enabled by default, so go figure out. Now more seriously, I think it belongs to core.
Eduardo Romero schrieb:
There was one time that a moron of a reviewer said Arch Linux sucks, because ssh was not enabled by default, so go figure out.
That guy probably didn't even try to understand the concept of Arch or otherwise he would have realized that virtually nothing is enabled by default.
Now more seriously, I think it belongs to core.
ACK!
On Fri, Jan 9, 2009 at 3:28 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
The new heimdal package I created depends on sqlite3 now because I replaced the included static copy of sqlite inside heimdal with the dynamic linked system installed version. Sqlite3 is in extra, while heimdal is in core. At this moment only ssh in core depends on heimdal. Do we move heimdal and ssh out of core into extra, or do we move sqlite3 into core? Any opinions?
I agree with most of the others that ssh should stay in core. What are the cons for moving sqlite to core? Does it pull in any other deps?
Am Fri, 9 Jan 2009 13:08:03 -0600 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
What are the cons for moving sqlite to core? Does it pull in any other deps?
I'm fine with moving sqlite3 into core. It doesn't pull additional deps. -Andy
On Fri, Jan 9, 2009 at 2:03 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Fri, 9 Jan 2009 13:08:03 -0600 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
What are the cons for moving sqlite to core? Does it pull in any other deps?
I'm fine with moving sqlite3 into core. It doesn't pull additional deps.
Same here. It seems a little bit weird, but that's just a feeling. If it's a dep, it's a dep. I say we throw it in core.
On Fri, Jan 9, 2009 at 3:05 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Jan 9, 2009 at 2:03 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Fri, 9 Jan 2009 13:08:03 -0600 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
What are the cons for moving sqlite to core? Does it pull in any other deps?
I'm fine with moving sqlite3 into core. It doesn't pull additional deps.
Same here. It seems a little bit weird, but that's just a feeling. If it's a dep, it's a dep. I say we throw it in core.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
No objection in moving sqlite3 to core. BTW, it has a makedepends on tcl. We should keep tcl in extra as several other package in core have makedepends on packages from extra.
Am Fri, 9 Jan 2009 16:33:56 -0500 schrieb "Eric Bélanger" <snowmaniscool@gmail.com>: BTW, it has a makedepends on
tcl. We should keep tcl in extra as several other package in core have makedepends on packages from extra.
That's something I really dislike. I try to keep my chroots clean wherever possible. -Andy
Andreas Radke wrote:
Am Fri, 9 Jan 2009 16:33:56 -0500 schrieb "Eric Bélanger" <snowmaniscool@gmail.com>:
BTW, it has a makedepends on
tcl. We should keep tcl in extra as several other package in core have makedepends on packages from extra.
That's something I really dislike. I try to keep my chroots clean wherever possible.
I don't understand what you mean there? Do you have a build chroot with only [core] enabled? Allan
Am Sat, 10 Jan 2009 12:47:31 +1000 schrieb Allan McRae <allan@archlinux.org>:
Andreas Radke wrote:
Am Fri, 9 Jan 2009 16:33:56 -0500 schrieb "Eric Bélanger" <snowmaniscool@gmail.com>:
BTW, it has a makedepends on
tcl. We should keep tcl in extra as several other package in core have makedepends on packages from extra.
That's something I really dislike. I try to keep my chroots clean wherever possible.
I don't understand what you mean there? Do you have a build chroot with only [core] enabled?
Allan
8 chroots here: core - core+extra - core/testing - core+extra/testing each for two architectures. -Andy
On Fri, Jan 9, 2009 at 10:54 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Fri, 9 Jan 2009 16:33:56 -0500 schrieb "Eric Bélanger" <snowmaniscool@gmail.com>:
BTW, it has a makedepends on
tcl. We should keep tcl in extra as several other package in core have makedepends on packages from extra.
That's something I really dislike. I try to keep my chroots clean wherever possible.
The Integrity Check tool can detect all repo hierarchy problems. Since I ran it on core/extra, it detected all the core -> extra makedependencies : http://archlinux.org/pipermail/arch-dev-public/2009-January/009692.html core/iputils depends on extra/opensp core/iputils depends on extra/libxslt core/iputils depends on extra/docbook-xsl core/madwifi-utils depends on extra/sharutils core/e2fsprogs depends on extra/bc core/ca-certificates depends on extra/ruby core/madwifi depends on extra/sharutils And the extra -> community makedependencies appear as missing since community was not considered : xosd --> 'xmms' flac --> 'xmms' gnome-speech --> 'espeak' I would like to know if that goal of having clean chroots is shared and if it's worth opening tasks on the bug tracker for these problems, or if it is a lost cause :)
On Sun, Jan 11, 2009 at 11:54 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Jan 9, 2009 at 10:54 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Fri, 9 Jan 2009 16:33:56 -0500 schrieb "Eric Bélanger" <snowmaniscool@gmail.com>:
BTW, it has a makedepends on
tcl. We should keep tcl in extra as several other package in core have makedepends on packages from extra.
That's something I really dislike. I try to keep my chroots clean wherever possible.
The Integrity Check tool can detect all repo hierarchy problems. Since I ran it on core/extra, it detected all the core -> extra makedependencies : http://archlinux.org/pipermail/arch-dev-public/2009-January/009692.html
core/iputils depends on extra/opensp core/iputils depends on extra/libxslt core/iputils depends on extra/docbook-xsl core/madwifi-utils depends on extra/sharutils core/e2fsprogs depends on extra/bc core/ca-certificates depends on extra/ruby core/madwifi depends on extra/sharutils
Check if these packages currently in extra have a (make)depends on other packages from extra and so on. If these packages depends on too many packages from extra, we might be better doing an exception and keep them in extra. Otherwise we should try to move them to core.
And the extra -> community makedependencies appear as missing since community was not considered :
xosd --> 'xmms' flac --> 'xmms'
The makedepends is to build plugins. It was brought up on the ML before and no-one objected. I maintain xmms in community so I could easily bring it back in extra. With a usage of 16.34 %, I would say it has a place in extra.
gnome-speech --> 'espeak'
I would like to know if that goal of having clean chroots is shared and if it's worth opening tasks on the bug tracker for these problems, or if it is a lost cause :)
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Am Sun, 11 Jan 2009 13:42:24 -0500 schrieb "Eric Bélanger" <snowmaniscool@gmail.com>:
And the extra -> community makedependencies appear as missing since community was not considered :
xosd --> 'xmms' flac --> 'xmms'
The makedepends is to build plugins. It was brought up on the ML before and no-one objected. I maintain xmms in community so I could easily bring it back in extra. With a usage of 16.34 %, I would say it has a place in extra.
xmms would pull gtk that we wanted to drop from extra. just a small question: will the new makepkg with split support allow to us to build for several repos(e.g. libs to core and documentation to extra)? -Andy
Andreas Radke schrieb:
just a small question: will the new makepkg with split support allow to us to build for several repos(e.g. libs to core and documentation to extra)?
The problem is not makepkg. The problem is how we will integrate split packages support into our repository scripts. Do we have any idea about that already? Allan, you did some work on package splitting, do you have an example PKGBUILD that demonstrates how this will work?
On Mon, Jan 12, 2009 at 7:13 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Andreas Radke schrieb:
just a small question: will the new makepkg with split support allow to us to build for several repos(e.g. libs to core and documentation to extra)?
The problem is not makepkg. The problem is how we will integrate split packages support into our repository scripts. Do we have any idea about that already?
Allan, you did some work on package splitting, do you have an example PKGBUILD that demonstrates how this will work?
I found an example there : http://dev.archlinux.org/~allan/splitpkg.html A relevant thread is there : http://archlinux.org/pipermail/pacman-dev/2008-December/007862.html I checked that splitpkg.html is the same example as PKGBUILD-split.proto. However, it seems allan's gitweb does not work anymore, allan broke it again! http://dev.archlinux.org/~allan/gitweb/gitweb.cgi
On Mon, Jan 12, 2009 at 12:13 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Andreas Radke schrieb:
just a small question: will the new makepkg with split support allow to us to build for several repos(e.g. libs to core and documentation to extra)?
The problem is not makepkg. The problem is how we will integrate split packages support into our repository scripts. Do we have any idea about that already?
Allan, you did some work on package splitting, do you have an example PKGBUILD that demonstrates how this will work?
I know, at the very least, the db-scripts are going to need updating to deal with split packages. We may have to rethink the way we handle "repo tagging" in svn. Any ideas would be appreciated.
Aaron Griffin schrieb:
I know, at the very least, the db-scripts are going to need updating to deal with split packages.
We may have to rethink the way we handle "repo tagging" in svn. Any ideas would be appreciated.
It could look like this: mysql/trunk mysql/repos/mysql/extra-{i686,x86_64} mysql/repos/mysql-clients/extra-{i686,x86_64} mysql/repos/mysql-libs/extra-{i686,x86_64} mysql-clients -> mysql mysql-libs -> mysql According to Subversion FAQ, we can use symlinks on Unix, but I don't know if that will work properly with the websvn stuff. This way, our repository scripts would not need much work and we can still upload the packages separately if we like.
Thomas Bächler wrote:
Aaron Griffin schrieb:
I know, at the very least, the db-scripts are going to need updating to deal with split packages.
We may have to rethink the way we handle "repo tagging" in svn. Any ideas would be appreciated.
It could look like this:
mysql/trunk mysql/repos/mysql/extra-{i686,x86_64} mysql/repos/mysql-clients/extra-{i686,x86_64} mysql/repos/mysql-libs/extra-{i686,x86_64} mysql-clients -> mysql mysql-libs -> mysql
According to Subversion FAQ, we can use symlinks on Unix, but I don't know if that will work properly with the websvn stuff.
This way, our repository scripts would not need much work and we can still upload the packages separately if we like.
That was pretty much how I was going to handle this. All our scripts have the do is detect the number of elements in pkgname and do the appropriate thing. I am going to start work on the devtools and db-scripts changes once I tidy up everything in makepkg. Xavier wrote:
However, it seems allan's gitweb does not work anymore, allan broke it again! http://dev.archlinux.org/~allan/gitweb/gitweb.cgi
From experience, this is a permissions issue. Dan fixed it last time and Jan the time before that. I can't access the log files on the server anymore to confirm that is the error so can someone look for me? Thanks, Allan Allan
On Mon, Jan 12, 2009 at 1:01 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Sun, 11 Jan 2009 13:42:24 -0500 schrieb "Eric Bélanger" <snowmaniscool@gmail.com>:
And the extra -> community makedependencies appear as missing since community was not considered :
xosd --> 'xmms' flac --> 'xmms'
The makedepends is to build plugins. It was brought up on the ML before and no-one objected. I maintain xmms in community so I could easily bring it back in extra. With a usage of 16.34 %, I would say it has a place in extra.
xmms would pull gtk that we wanted to drop from extra.
Well, there is already several packages in extra that depends on gtk. Unless we want to remove them all, we have no choice but to keep gtk in extra. So putting back xmms in extra won't really affect the gtk situation as it will just be another package depending on gtk. I don't see any problems in keeping gtk/glib in extra. FTR, I am maintaining them and they are low-maintenance as you would expect.
just a small question: will the new makepkg with split support allow to us to build for several repos(e.g. libs to core and documentation to extra)?
-Andy
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (10)
-
Aaron Griffin
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Dusty Phillips
-
Eduardo Romero
-
Eric Bélanger
-
Jan de Groot
-
Thomas Bächler
-
Xavier