I have a package with a library that needs to be entered to
/etc/ld.so.preload. It is clear that this library needs to go in /lib
rather than /usr/lib because there are systems that have /usr on a
dedicated partition.
But how do I handle the entry to /etc/ld.so.preload? There are
packages that le
On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey
<[EMAIL PROTECTED]> wrote:
>Why not just /etc/foorc or /etc/foo.conf or something like that?
Because the conffile is not a "real" conffile, but rather a shell
script being sourced in, and /etc/foo.conf will probably suggest that
this conffile is an
--- Sam Hartman <[EMAIL PROTECTED]> wrote: > >
"Michèl" == Michèl Alexandre Salim
> <[EMAIL PROTECTED]> writes:
> And if you come up with a clean solution for the
> changelog issue, I
> agree this is worth doing. If you do that, please
> let me know what
> your solution is.
>
As Richard Atte
> "Michèl" == Michèl Alexandre Salim <[EMAIL PROTECTED]> writes:
>>
Michèl> The reason I raise this issue in the first place is
Michèl> actually a notion that it would be nice for users wanting
Michèl> bleeding-edge software to update from CVS and just run
Michèl> debian/r
On Mon, Jun 04, 2001 at 06:31:54PM +0100, Michèl Alexandre Salim wrote:
[debian/ in upstream makes maintaining package difficult]
> The reason I raise this issue in the first place is actually a
> notion that it would be nice for users wanting bleeding-edge
> software to update from CVS and just r
On Mon, Jun 04, 2001 at 10:31:18AM +0200, Marc Haber wrote:
> Hi,
>
> let's say I have a package foo with a binary foo. The author suggests
> the one should have a shell script wrapper to be able to call the foo
> binary with the appropriate options. I want to do so in my package.
>
> - Have the
> "Michèl" == Michèl Alexandre Salim <[EMAIL PROTECTED]> writes:
Michèl> Hello, A general observation of Unix programs in general -
Michèl> a lot more of them come with RPM spec files, even
Michèl> generates them automatically from a spec.in file, than
Michèl> with debian scri
--- Josip Rodin <[EMAIL PROTECTED]> wrote: > On Sun,
Jun 03, 2001 at 11:40:26PM -0300, Henrique
> de Moraes Holschuh wrote:
> files there. Even if
> > upstream keeps its debian/ up-to-date, it will
> still cause you trouble if
> > you have to remove a file, as you'll need to
> either use dirty t
Hello,
A brief follow-up to my post last weekend. The current
status of my test packages are as follows:
GLib - packages created. RFC - I am not a seasoned
developer (yet!), any advice more than welcome.
Gtk-doc - needed if you want to recompile GNOME CVS
modules (including GLib). I have packag
--- Robert Bihlmeyer <[EMAIL PROTECTED]> wrote: >
Michèl Alexandre Salim <[EMAIL PROTECTED]>
> writes:
>
> > Have not managed to package Pango - can anyone
> assist me in finding
> > out what is going wrong? Basically the package
> failed the install
> > stage of the rules script if installed us
Marc Haber wrote:
> This is the way to do it for an init script. Is it OK to have a file
> in /etc/default that does not provider defaults for an init script
> but for an executeable called by users?
I don't know. I don't see a lot of advantage over just putting the
conffile in /etc.
There is s
On Sun, Jun 03, 2001 at 11:40:26PM -0300, Henrique de Moraes Holschuh wrote:
> Most of the time, no. Upstream debian/ cruft gets in the way of the updated
> debian/ files, especially if you need to delete files there. Even if
> upstream keeps its debian/ up-to-date, it will still cause you trouble
Andreas Bombe <[EMAIL PROTECTED]> writes:
> It's just that making the package non-native makes it easier to
> handle unless it's really a native package (i.e. written
> specifically for Debian).
YMMV, obviously. I find it easier to maintain quintuple-agent without
Debian subversions; "native" if
Russell Coker <[EMAIL PROTECTED]> writes:
> On Monday 04 June 2001 00:59, Julian Gilbey wrote:
> > On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> > > Another thing any package that depends on the creation of nodes under
> > > /dev MUST depend on "makedev | devfsd". People who r
On Sun, Jun 03, 2001 at 11:40:26PM -0300, Henrique de Moraes Holschuh wrote:
> Most of the time, no. Upstream debian/ cruft gets in the way of the updated
> debian/ files, especially if you need to delete files there. Even if
> upstream keeps its debian/ up-to-date, it will still cause you troubl
On Monday 04 June 2001 10:34, Hamish Moffatt wrote:
> On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> > Another thing any package that depends on the creation of nodes under
> > /dev MUST depend on "makedev | devfsd". People who run devfsd do not
> > need to have makedev installed
On Monday 04 June 2001 00:59, Julian Gilbey wrote:
> On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> > Also make the package check for the presence of the character device
> > /dev/.devfsd first, if that device exists then your script must not
> > attempt to create the device node
On Sun, Jun 03, 2001 at 07:23:08PM -0400, Joey Hess wrote:
> Julian Gilbey wrote:
> > Agreed. (And I don't think /usr/share/ is mandated.)
>
> Every package MUST be accompanied by a verbatim copy of its copyright
> and distribution license in the file
> `/usr/share/doc/__/copyright
On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> Another thing any package that depends on the creation of nodes under /dev
> MUST depend on "makedev | devfsd". People who run devfsd do not need to have
> makedev installed.
Well, makedev is priority: required and section: base.
Hi,
let's say I have a package foo with a binary foo. The author suggests
the one should have a shell script wrapper to be able to call the foo
binary with the appropriate options. I want to do so in my package.
- Have the foo-Binary in /usr/lib/foo/foo
- Have a foo shell script wrapper in /usr/b
On Monday 04 June 2001 10:34, Hamish Moffatt wrote:
> On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> > Another thing any package that depends on the creation of nodes under
> > /dev MUST depend on "makedev | devfsd". People who run devfsd do not
> > need to have makedev installe
On Monday 04 June 2001 00:59, Julian Gilbey wrote:
> On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> > Also make the package check for the presence of the character device
> > /dev/.devfsd first, if that device exists then your script must not
> > attempt to create the device node
On Sun, Jun 03, 2001 at 07:23:08PM -0400, Joey Hess wrote:
> Julian Gilbey wrote:
> > Agreed. (And I don't think /usr/share/ is mandated.)
>
> Every package MUST be accompanied by a verbatim copy of its copyright
> and distribution license in the file
> `/usr/share/doc/__/copyrigh
On Sun, Jun 03, 2001 at 02:37:19PM +0200, Russell Coker wrote:
> Another thing any package that depends on the creation of nodes under /dev
> MUST depend on "makedev | devfsd". People who run devfsd do not need to have
> makedev installed.
Well, makedev is priority: required and section: base.
Hi,
let's say I have a package foo with a binary foo. The author suggests
the one should have a shell script wrapper to be able to call the foo
binary with the appropriate options. I want to do so in my package.
- Have the foo-Binary in /usr/lib/foo/foo
- Have a foo shell script wrapper in /usr/
--- Robert Bihlmeyer <[EMAIL PROTECTED]> wrote: >
Michèl Alexandre Salim <[EMAIL PROTECTED]>
> writes:
>
> [your mail formatting was totally messed up, BTW]
>
Yes, sorry about that :) Using the university's
network connection to do most of my e-mailing and
somehow or another it is fraught with pr
26 matches
Mail list logo
