Paul Wise wrote:
> Please file bugs about obsolete conffiles when you find new ones. The
> packages themselves should clean up their obsolete conffiles.
Is there a bug example or two you could point me to so that I can
follow the standard template of reporting these problems? It appears
I have so
Paul Wise wrote:
> Bob Proulx wrote:
> > How can I as a system administrator clean that obsolete conffile up?
>
> rm -f /etc/some-obsolete-conffile
> apt-get --reinstall install package-that-provided-the-obsolete-conffile
Ah! Thanks. That works.
> > I have many obsolet
I have many obsolete conffiles on my system. It has been upgraded
through many releases.
dpkg-query -W -f='${Conffiles}\n' | grep obsolete
Picking a simple one as an example:
/etc/skel/.bash_profile d1a8c44e7dd1bed2f3e75d1343b6e4e1 obsolete
If I purge the package and install it fresh then t
Russ Allbery wrote:
> Bob, I've uploaded the latest version. Thank you for your work!
Thanks!
Bob
signature.asc
Description: Digital signature
. What is your desire? I am getting a little nervous about
getting the current update uploaded before the freeze. I would like
to be ahead of the wave and get through the autobuilders.
Thanks!
Bob
Russ Allbery wrote:
> Bob Proulx writes:
> > It was. But then Russ Allbery noted some
ormatting. Thanks Bjarni Ingi Gislason.
(Closes: #663260)
-
+ * Fix man page formatting oddities. Thanks Russ Allbery for the nice patch.
+See Bug#677013#68 for the discussion.
+ * Fix texinfo standalone info program navigation oddity. Reported by
+Russ Allbery. See Bug#677013#63.
+
Russ Allbery wrote:
> * There seems to be something odd about the time info file. If I run info
> time, and then press space, rather than proceeding to the next child
> node the way that info normally does, info just reports "no more nodes
> in this file." The same is true at a few points i
Russ Allbery wrote:
> * The formatting of the man page isn't great. There are a few places that
> seem to have spurious line breaks (the --append documentation, for
> example),
That appears to have been some spurious spaces in bad places in the
man page. Fixed.
> and it's traditional to h
Bart Martens wrote:
> Bob Proulx wrote:
> > Bart Martens wrote:
> > > The file debian/copyright "should name the original authors", and
> > > David Keppel is such an author.
I have looked through many copyright files and do not see one that
does this. See
Tobias
Copyright 1995-2004 Dirk Eddelbuettel
Copyright 2005, 2008 Tollef Fog Heen
Copyright 2010 Salvatore Bonaccorso
Copyright 2012 Bob Proulx
License: GPL-2+
Files: debian/time.1
Copyright: Copyright 1996 Dirk Eddelbuettel
License: freely redistributable
Copyri
The latest 'time' package release candidate is here:
http://www.proulx.com/~bob/debian/pool/sid/main/time/2012-06-21/
-rw-r--r-- 1 16649 Jun 21 13:38 time_1.7-24.debian.tar.gz
-rw-rw-r-- 1 1038 Jun 21 13:48 time_1.7-24.dsc
-rw-r--r-- 1 12317 Jun 21 13:39 time_1.7-24_amd64.build
-rw-
Ferenc Wagner wrote:
> Bob Proulx writes:
> > Yes. But note that those had been made before too. I only updated
> > the autotools files (again) because the current ones were quite aged
> > and dearly in need of being updated. Those were not "patched" in the
>
Sandro Tosi wrote:
> Hello Bob,
> here's a brief review of the package.
Thank you for reviewing the package!
> debian/changelog
> - don't rewrite history, so please restore the old changelog entries,
> even if they have a weird "Closes=xxx" in the first entry line
The two entries are:
time (1
Sandro Tosi wrote:
> Bart Martens wrote:
> > Package: sponsorship-requests
> > Owner: Bob Proulx
> >
> > I'm opening this RFS on behalf of Bob Proulx who owns ITA 652670.
> >
> > Bob Proulx wrote:
> >> Hi Bart,
> >>
> >> &g
What is the best procedure to use for removing a stop script from a
package?
Moving from:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
dh_installinit
To:
# Default-Start: 2 3 4 5
# Default-Stop:
dh_installinit --update-rcd-params="start 99 2 3 4 5 ."
If nothing mor
Ansgar Burchardt wrote:
> Sven Joachim wrote:
> > Bob Proulx wrote:
> >> I am hoping to understand the "obsolete" flag on conffiles in the dpkg
> >> status file. There are many packages that include this flag at the
> >> end of the line. For exam
I am hoping to understand the "obsolete" flag on conffiles in the dpkg
status file. There are many packages that include this flag at the
end of the line. For example:
Package: file
Conffiles:
/etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete
/etc/magic 272913026300e7ae9b5e2d51f138e674
PJ Weisberg wrote:
> Ben Hutchings wrote:
> > Don't even think of doing this in a package uploaded to Debian.
>
> Right. I mentioned it mostly for completness, since it's the answer
> to the question that was actually asked. I almost added, "I don't
> think any Debian packages actually do this,"
Ben Finney wrote:
> Richard Hector writes:
> > We've run into an issue here, when we deploy a package (created
> > in-house) on a system that uses NFS for some filesystems. Due to
> > root-squashing, the postinst can't create or chmod/chown the files it
> > needs to.
> ...
> * You're root-squashing
Recai Oktas wrote:
> Steve Langasek wrote:
> > awk is "virtually essential": it can't be Essential: yes because
> > that would prevent removing mawk in favor of gawk, but awk is a
> > dependency of another essential package to ensure that you can use
> > basic awk functionality without having to de
I need a clarification because I am confused. If I have a script that
uses awk do I need the package to "Depends: awk"? Or is awk like
basename where we are able to assume it is on the system without any
explicit dependencies?
I see that many packages do "Depends: awk". But awk is an alternativ
Henrique de Moraes Holschuh wrote:
> Then tell the user that, and DO NOT TOUCH /etc/inittab.
> ...
> Yes. But AFAIK there are absolutely no plans to provide an interface for
> ANY package to touch /etc/inittab. Screwing it up is so utterly callous,
> that one would have to be out of his mind to e
Stefano Zacchiroli wrote:
> Are there any problem in uploading packages built inside that chroot?
It should be fine. In fact that is a recommended practice. It
prevents flavor from the developer's machine leaking into the build.
The 'pbuilder' package is very nice for managing these types of
chr
John Skaller wrote:
> (a) it does not provide binary packages
> (b) apt tools can't build from source
>
> The latter is exceptionally annoying (which I consider
> a very polite form of what I'd like to actually say ;)
>
> Is there a tool which does that?
>
> I use Synaptic GUI tool, it would be
gregor herrmann wrote:
> On Thu, Jul 07, 2005 at 08:15:06PM +0200, Rakotomandimby Mihamina wrote:
> > But what and how should I separate the created files?
> > Should I put them into the same directory? orig, diff, dsc,.. in a flat
> > way? I guess yes
>
> Yup.
>
> Maybe you'd like to take a look
Rakotomandimby Mihamina wrote:
> I want to make a rpm-spec-mode package in order to create RPM specfiles
> under Debian.
Unfortunately I don't know anything about your problem building your
package. But I just wanted to note that emacs already comes with a
mode for dealing with rpm spec files. I
John Hendrickson wrote:
> Why in the world did DMs compile KDE to say: You must use LessTif and
> uninstall Motif???
What kde package requires lesstif? I was unable to locate one using
'apt-cache showpkg lesstif1' and 'apt-cache showpkg lesstif2'.
Note that lesstif1 and lesstif2 implement versio
Jarle Aase wrote:
> I'm about to make some .deb packages. Some will hopefully be accepted as
> official packages, while others will be built for my own convenience (to
> ease installation and upgrades on Debian servers I maintain).
>
> The packages includes shared C++ libraries, binaries, database
Anthony Towns wrote:
> GNU Interactive Tools hasn't seen an upstream update at all since 2001,
> and looking at the diffs since .18, doesn't seem to have had any
> significant changes since 1999. The Debian updates seem mostly to be
> updating the build system, rather than user-visible changes.
Jarno Elonen wrote:
> ..and the said utility script looks like this:
>
>
> source /etc/upgrade-system.conf
>
> echo "Updating available package lists..."
> apt-get -q=2 update
Are you randomizing your start time? Look at cron-apt for an example.
Otherwise th
Steven Augart wrote:
> First, a retraction:
>
> James Damour wrote:
> >On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
> >>As you probably know, when a shell sees that it is running a setuid or
> >>setgid shell script, it detects this because the euid and ruid or egid
> >>and rgid are differen
Jarno Elonen wrote:
> ..and the said utility script looks like this:
>
>
> source /etc/upgrade-system.conf
>
> echo "Updating available package lists..."
> apt-get -q=2 update
Are you randomizing your start time? Look at cron-apt for an example.
Otherwise th
Steven Augart wrote:
> First, a retraction:
>
> James Damour wrote:
> >On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
> >>As you probably know, when a shell sees that it is running a setuid or
> >>setgid shell script, it detects this because the euid and ruid or egid
> >>and rgid are differen
Halim Boukaram wrote:
> I've finished making the rpm for my package.
>
> Should i convert it to a 'deb' file (using alien)
> before trying to get it uploaded to debian test folder
> or should it be rpm or tarred.
The 'alien' program is really good. But it is not perfect. And we
would like Debia
Halim Boukaram wrote:
> I've finished making the rpm for my package.
>
> Should i convert it to a 'deb' file (using alien)
> before trying to get it uploaded to debian test folder
> or should it be rpm or tarred.
The 'alien' program is really good. But it is not perfect. And we
would like Debia
Frank Küster wrote:
> Colin Watson <[EMAIL PROTECTED]> schrieb:
> > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> > available; that way you get less confused by /etc.
> [..]
> Hm, how do I know (other by trial and error) whether a package supports
> this? autoconf'iscated
Frank Küster wrote:
> Colin Watson <[EMAIL PROTECTED]> schrieb:
> > It's easier to use DESTDIR=$(CURDIR)/debian/tmp if DESTDIR support is
> > available; that way you get less confused by /etc.
> [..]
> Hm, how do I know (other by trial and error) whether a package supports
> this? autoconf'iscated
Rene Engelhard wrote:
> Bob Proulx wrote:
> > Why does building a package with pbuilder generate the seemingly wrong
> > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
> > installed library? What am I doing wrong?
>
> Nothing.
>
> [EMAIL
Rene Engelhard wrote:
> Bob Proulx wrote:
> > Why does building a package with pbuilder generate the seemingly wrong
> > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
> > installed library? What am I doing wrong?
>
> Nothing.
>
> [EMAIL
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
s
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
s
John Lightsey wrote:
> If anyone with a non-x86 machine would like to take a look again and give
> feedback on wheter or not it compiles properly, I'd really appreciate it.
> The build logs that I recieved were very helpfull.
I grabbed that and gave it another run. There are still -O9
referenc
John Lightsey wrote:
> If anyone with a non-x86 machine would like to take a look again and give
> feedback on wheter or not it compiles properly, I'd really appreciate it.
> The build logs that I recieved were very helpfull.
I grabbed that and gave it another run. There are still -O9
referenc
John Lightsey wrote:
> I'm trying to adopt xmms-goom which has a release critical bug related to
> !x86 architectures. I believe the version I've packaged fixes the problem,
> but I don't have access to a !x86 machine running unstable to test it on. If
> someone could download, build, and test
John Lightsey wrote:
> I'm trying to adopt xmms-goom which has a release critical bug related to
> !x86 architectures. I believe the version I've packaged fixes the problem,
> but I don't have access to a !x86 machine running unstable to test it on. If
> someone could download, build, and test
Christoph Berg wrote:
> Re: Bob Proulx in <[EMAIL PROTECTED]>
> > perl -e 'printf("%o\n",(stat($ARGV[0]))[2]);' /tmp # print mode in octal
> > 41777
> >
> > My only question now is where did that '4' come from in the mode? But
Christoph Berg wrote:
> Re: Bob Proulx in <[EMAIL PROTECTED]>
> > perl -e 'printf("%o\n",(stat($ARGV[0]))[2]);' /tmp # print mode in octal
> > 41777
> >
> > My only question now is where did that '4' come from in the mode? But
Frank Küster wrote:
> stat is called to get uid and exact permissions of a temporary
> configuration file which has just been created.
Perl is standard on systems. I hesitate to put more use of it in init
scripts but... Perhaps this would be of use instead of stat just to
work around this proble
Andreas Metzler wrote:
> Frank Küster wrote:
> > in a package that I maintain (sponsored by a DD), I use a call to
> > stat. In sarge, /usr/bin/stat is in coreutils - of course I don't need a
> > dependency on that. However, in woody stat was in a separate
> > package. Usually packages keep really
Frank Küster wrote:
> stat is called to get uid and exact permissions of a temporary
> configuration file which has just been created.
Perl is standard on systems. I hesitate to put more use of it in init
scripts but... Perhaps this would be of use instead of stat just to
work around this proble
Andreas Metzler wrote:
> Frank Küster wrote:
> > in a package that I maintain (sponsored by a DD), I use a call to
> > stat. In sarge, /usr/bin/stat is in coreutils - of course I don't need a
> > dependency on that. However, in woody stat was in a separate
> > package. Usually packages keep really
I am setting up a scripted update for a pool of machines and trying to
understand the ramifications.
In the dpkg man page:
confnew: If a conffile has been modified always
install the new version without prompting, unless
the --force-confdef is also
I am setting up a scripted update for a pool of machines and trying to
understand the ramifications.
In the dpkg man page:
confnew: If a conffile has been modified always
install the new version without prompting, unless
the --force-confdef is also
Matthias Urlichs wrote:
> > As packages are normally upgraded through the life of a system I train
> > people to always say 'Y' to the replace a conffile question. Sure
> > this may leave the system in a generic and locally unworkable state.
>
> So why not "N"? That may leave the package, at wors
Matthias Urlichs wrote:
> > As packages are normally upgraded through the life of a system I train
> > people to always say 'Y' to the replace a conffile question. Sure
> > this may leave the system in a generic and locally unworkable state.
>
> So why not "N"? That may leave the package, at wors
Andrei Mitrofanow wrote:
> nobody interestet to fvwm-themes?
> http://smilebef.homelinux.org/~smilebef/
[Reading my note before sending it I see it sounds harsh. I don't
mean it that way. I mean it constructively so that you will know why
I personally have not tried any of your packages. Please
Andrei Mitrofanow wrote:
> nobody interestet to fvwm-themes?
> http://smilebef.homelinux.org/~smilebef/
[Reading my note before sending it I see it sounds harsh. I don't
mean it that way. I mean it constructively so that you will know why
I personally have not tried any of your packages. Please
Eric Winger wrote:
> Can't I even "Depend" on a package and then fine tune its configuration
> though?
I don't think you can depend upon a package and tweak its
conffiles. It would be interesting to be able to do that and it
certainly makes sense from an object oriented inherit and modify
viewpo
Eric Winger wrote:
> Can't I even "Depend" on a package and then fine tune its configuration
> though?
I don't think you can depend upon a package and tweak its
conffiles. It would be interesting to be able to do that and it
certainly makes sense from an object oriented inherit and modify
viewpo
David Meggy wrote:
> Searching the mailing lists, oddly shows up nothing. I think the debian
> mailing list search page needs some fixing.
I think this was in debian-devel. Since I had the page up in my
browser when I read your message here it is.
http://people.debian.org/~rmurray/c++transiti
David Meggy wrote:
> Searching the mailing lists, oddly shows up nothing. I think the debian
> mailing list search page needs some fixing.
I think this was in debian-devel. Since I had the page up in my
browser when I read your message here it is.
http://people.debian.org/~rmurray/c++transiti
Eric Winger wrote:
> would it be sacreligious to ask why sources are kept in non-free?
You are asking an obvious question and the answer is the obvious one.
The sources are in non-free because they are not free. Look at the
copyrights of any of the packages in non-free and you will see that
they
Eric Winger wrote:
> would it be sacreligious to ask why sources are kept in non-free?
You are asking an obvious question and the answer is the obvious one.
The sources are in non-free because they are not free. Look at the
copyrights of any of the packages in non-free and you will see that
they
Andreas Metzler wrote:
> Frank Kuster wrote:
> >users working with Debian woody often do not look at archived bugs when
> >reporting bugs on a package. Therefore it is likely that bugs that have
> >long been fixed in unstable, but will never be in woody will be reported
> >multiple times again.
I
Andreas Metzler wrote:
> Frank Kuster wrote:
> >users working with Debian woody often do not look at archived bugs when
> >reporting bugs on a package. Therefore it is likely that bugs that have
> >long been fixed in unstable, but will never be in woody will be reported
> >multiple times again.
I
Brian Nelson wrote:
> > Would it be somehow possible to change the default behavior?
> > [of debuild to be debuild -uc -us]
> Uh, have you filed a wishlist bug?
Good idea! Just did that. Bug#194678
Bob
pgpfOUP2e7fXk.pgp
Description: PGP signature
Colin Watson wrote:
> I actually don't see how dpkg-buildpackage's
> sign-immediately-after-build defaults ever make sense (except when
> dpkg-buildpackage was originally written, when debsign didn't yet
> exist). Why would you want to waste time signing a package you haven't
> tested yet? Surely t
Matthew Palmer wrote:
> Out of interest, are there any MUAs which have a separate "reply to list"
> function?
KDE's 'kmail' for those into GUIs to read text. But you have to
configure the list address on a per folder basis.
Bob
pgpKg8pXDLrj4.pgp
Description: PGP signature
Tony Maro wrote:
> Why do I feel like I opened a can of worms?
It is that squirmy feeling in the gut. Like just before the alien
claws its way out.
Bob
pgpClP4tDDzjT.pgp
Description: PGP signature
The released version of Debian is 'stable. Why are bug reports closed
against 'sid'? Shouldn't bug reports be closed only in released
versions of Debian? What am I missing? Requesting education.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-handling
5.8.4 When bugs
The released version of Debian is 'stable. Why are bug reports closed
against 'sid'? Shouldn't bug reports be closed only in released
versions of Debian? What am I missing? Requesting education.
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-handling
5.8.4 When bugs
Neil L. Roeth wrote:
> Examining the buildd logs showed it tried to run automake to build
> [...]
> But, *why* did this happen? I had created Makefile.in in the source
> tree after aclocal.m4, so it was a *newer* file there and did not
> trigger a call to automake on my build machine.
You asked
Neil L. Roeth wrote:
> Examining the buildd logs showed it tried to run automake to build
> [...]
> But, *why* did this happen? I had created Makefile.in in the source
> tree after aclocal.m4, so it was a *newer* file there and did not
> trigger a call to automake on my build machine.
You asked
Bastian Kleineidam wrote:
> On Fri, Feb 28, 2003 at 08:19:51PM +0100, Henning Moll wrote:
> > In addition i have some questions to the Depends section in
> > debian/control: ${shlibs:Depends} is a nice feature, but i think
> > for many packages/libraries it is way to strict, because it's
> > always
Bastian Kleineidam wrote:
> On Fri, Feb 28, 2003 at 08:19:51PM +0100, Henning Moll wrote:
> > In addition i have some questions to the Depends section in
> > debian/control: ${shlibs:Depends} is a nice feature, but i think
> > for many packages/libraries it is way to strict, because it's
> > always
Aaron Haviland wrote:
> Bob Proulx cursed the gypsies with this chant:
> > Bug 179614! It appears to me that this is a similar but not quite
> > identical problem. In that bug the packages were all real packages
> > and none of them were virtual. I could not deduce that
Aaron Haviland wrote:
> Bob Proulx cursed the gypsies with this chant:
> > Bug 179614! It appears to me that this is a similar but not quite
> > identical problem. In that bug the packages were all real packages
> > and none of them were virtual. I could not deduce that
Colin Watson wrote:
> It's a false positive, yes. Please file it as a bug against lintian
> (also compare #179614).
Bug 179614! It appears to me that this is a similar but not quite
identical problem. In that bug the packages were all real packages
and none of them were virtual. I could not ded
Colin Watson wrote:
> It's a false positive, yes. Please file it as a bug against lintian
> (also compare #179614).
Bug 179614! It appears to me that this is a similar but not quite
identical problem. In that bug the packages were all real packages
and none of them were virtual. I could not ded
Matt Zimmerman wrote:
> > Why does it think rsh-client is a virtual package?
>
> It is a mixed virtual package. There is a real package rsh-client, but also
> several other packages provide rsh-client (apt-cache showpkg rsh-client).
Aha! Interesting. Since I *knew* that rsh-client was a real p
Matt Zimmerman wrote:
> > Why does it think rsh-client is a virtual package?
>
> It is a mixed virtual package. There is a real package rsh-client, but also
> several other packages provide rsh-client (apt-cache showpkg rsh-client).
Aha! Interesting. Since I *knew* that rsh-client was a real p
I am unable to determine why I am getting this message from lintian.
Help?
My control file seems normal to me with this header. I am attempting
to build a meta package that contains nothing but depends so that I
can pull in various packages easily by installing my metapackage.
I have reduced the
I am unable to determine why I am getting this message from lintian.
Help?
My control file seems normal to me with this header. I am attempting
to build a meta package that contains nothing but depends so that I
can pull in various packages easily by installing my metapackage.
I have reduced the
Chad Miller wrote:
> On Sun, Jan 26, 2003 at 09:12:21AM +0100, Szilveszter Farkas wrote:
> > i would like to create a package which needs a system user and a group
> > to be added. which uid/gid shall i use? leave it over 1000 (default),
> > or should i set it under 1000?
>
> There's policy alread
Chad Miller wrote:
> On Sun, Jan 26, 2003 at 09:12:21AM +0100, Szilveszter Farkas wrote:
> > i would like to create a package which needs a system user and a group
> > to be added. which uid/gid shall i use? leave it over 1000 (default),
> > or should i set it under 1000?
>
> There's policy alread
Andrew Stribblehill <[EMAIL PROTECTED]> [2002-11-08 15:49:27 +]:
> I can see a number of ways out of it, but have no clear idea which is
> best:
>
> * Split the package into its component parts, such that each daemon
> is in a separate package. Have an init script for each. The admin
> cho
Andrew Stribblehill <[EMAIL PROTECTED]> [2002-11-08 15:49:27 +]:
> I can see a number of ways out of it, but have no clear idea which is
> best:
>
> * Split the package into its component parts, such that each daemon
> is in a separate package. Have an init script for each. The admin
> cho
Drew Parsons <[EMAIL PROTECTED]> [2002-10-14 00:41:49 +1000]:
> OK, I'll try to remember to restrip for sarge :)
Perhaps the BTS could be a help in remembering this?
Bob
pgpoGeZUVTmOR.pgp
Description: PGP signature
Drew Parsons <[EMAIL PROTECTED]> [2002-10-14 00:41:49 +1000]:
> OK, I'll try to remember to restrip for sarge :)
Perhaps the BTS could be a help in remembering this?
Bob
msg07487/pgp0.pgp
Description: PGP signature
Jay Graves <[EMAIL PROTECTED]> [2002-10-10 16:39:18 -0600]:
> > debian/rules should have something like this:
> > make install DESTDIR=$(CURDIR)/debian/tmp
>
> well my debian rules looks like this
> ./configure (lots of stuff here) --datadir=/etc/X11
This implies that the application is using dat
Jay Graves <[EMAIL PROTECTED]> [2002-10-10 16:39:18 -0600]:
> > debian/rules should have something like this:
> > make install DESTDIR=$(CURDIR)/debian/tmp
>
> well my debian rules looks like this
> ./configure (lots of stuff here) --datadir=/etc/X11
This implies that the application is using dat
Junichi Uekawa <[EMAIL PROTECTED]> [2002-09-22 20:54:19 +0900]:
> What would be the point of restricting the shared libraries to
> within the software ?
The traditional argument is usually that shared libraries save disk
space. If your have a large amount of code that is completely shared
between
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]:
BTW, I wanted to also say...
> I know of three ways to deal with this one -- add a new path to
> ld.so.conf (yuck),
Blech! Very yucky taste in mouth. ;-)
> link with -rpath, or wrap the apps in a script which alters
> $LD_LIBRARY
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]:
> I'm working on a package containing several executables, whose common
> functionality lives in a few shared libraries. They're linked in the
> usual way at compile time. Policy says they should live in
> /usr/lib/packagename/, but
Junichi Uekawa <[EMAIL PROTECTED]> [2002-09-22 20:54:19 +0900]:
> What would be the point of restricting the shared libraries to
> within the software ?
The traditional argument is usually that shared libraries save disk
space. If your have a large amount of code that is completely shared
betwee
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]:
BTW, I wanted to also say...
> I know of three ways to deal with this one -- add a new path to
> ld.so.conf (yuck),
Blech! Very yucky taste in mouth. ;-)
> link with -rpath, or wrap the apps in a script which alters
> $LD_LIBRAR
Devin Carraway <[EMAIL PROTECTED]> [2002-09-22 01:35:32 -0700]:
> I'm working on a package containing several executables, whose common
> functionality lives in a few shared libraries. They're linked in the
> usual way at compile time. Policy says they should live in
> /usr/lib/packagename/, but
Marco Presi <[EMAIL PROTECTED]> [2002-09-08 22:45:23 +0200]:
> I am packaging a multiple binary from a single sources. The two
> binaries provides the same server functionality and differs just for
> compilation options, let's say:
>
> "server" and "server-enhanced".
Are they overlapping pac
Marco Presi <[EMAIL PROTECTED]> [2002-09-08 22:45:23 +0200]:
> I am packaging a multiple binary from a single sources. The two
> binaries provides the same server functionality and differs just for
> compilation options, let's say:
>
> "server" and "server-enhanced".
Are they overlapping pa
99 matches
Mail list logo
