On Thu, Mar 22, 2001 at 06:06:52PM -0600, Steve Langasek wrote:
> On Thu, 22 Mar 2001, Chad C. Walstrom wrote:
>
> > On Wed, Mar 21, 2001 at 01:00:46PM -0600, Chad C. Walstrom wrote:
> > > I was wondering if there was a standard policy regarding libraries of
> > >
On Thu, Mar 22, 2001 at 06:06:52PM -0600, Steve Langasek wrote:
> On Thu, 22 Mar 2001, Chad C. Walstrom wrote:
>
> > On Wed, Mar 21, 2001 at 01:00:46PM -0600, Chad C. Walstrom wrote:
> > > I was wondering if there was a standard policy regarding libraries of
> > >
On Wed, Mar 21, 2001 at 01:00:46PM -0600, Chad C. Walstrom wrote:
> I was wondering if there was a standard policy regarding libraries of
> php routines; those dependent upon a given version of php and those
> independent. Where do I place the files in a library package f
On Wed, Mar 21, 2001 at 01:00:46PM -0600, Chad C. Walstrom wrote:
> I was wondering if there was a standard policy regarding libraries of
> php routines; those dependent upon a given version of php and those
> independent. Where do I place the files in a library package f
I was wondering if there was a standard policy regarding libraries of
php routines; those dependent upon a given version of php and those
independent. Where do I place the files in a library package for
php4:
/usr/{share|lib}/
/usr/{share|lib}/php/
I intend on packaging the PHP4
I was wondering if there was a standard policy regarding libraries of
php routines; those dependent upon a given version of php and those
independent. Where do I place the files in a library package for
php4:
/usr/{share|lib}/
/usr/{share|lib}/php/
I intend on packaging the PHP4
Just wanted to give people a heads-up. I'm trying to roll in the
patch that was made to correct the temp file security problem. The
original patch did not apply cleanly to the new upstream source, so
I'll need to squirrel away some time to do some coding and debugging
-- perhaps sometime tonight.
Just wanted to give people a heads-up. I'm trying to roll in the
patch that was made to correct the temp file security problem. The
original patch did not apply cleanly to the new upstream source, so
I'll need to squirrel away some time to do some coding and debugging
-- perhaps sometime tonight
peter karlsson wrote:
> I would prefer not to make unnecessary copies...
I think you're referring to the local repository as being unnecessary,
in which case I'd agree with you. However, if you do use local
repositories and do not have direct upstream CVS access, vendor
branchanes are far too con
peter karlsson wrote:
> I would prefer not to make unnecessary copies...
I think you're referring to the local repository as being unnecessary,
in which case I'd agree with you. However, if you do use local
repositories and do not have direct upstream CVS access, vendor
branchanes are far too co
Regarding: Debian native package v.s. Upstream *.orig.tar.gz + *.diff
Joshua Haberman wrote:
> Really? I was told by someone else that it makes things much more
> complicated, since you have to release a new upstream version for
> any debian-specific changes to be made. I'll refrain from quoting
>
Regarding: Debian native package v.s. Upstream *.orig.tar.gz + *.diff
Joshua Haberman wrote:
> Really? I was told by someone else that it makes things much more
> complicated, since you have to release a new upstream version for
> any debian-specific changes to be made. I'll refrain from quoting
On Mon, Feb 12, 2001 at 09:25:26PM +0100, peter karlsson wrote:
> I have CVS access to a upstream program I am the Debian maintainer for
> (jwhois), and since I have learnt the lesson of moving the debian
> directory in the CVS, I'm planning to add them as a separate module.
>
> My question, howev
On Mon, Feb 12, 2001 at 09:25:26PM +0100, peter karlsson wrote:
> I have CVS access to a upstream program I am the Debian maintainer for
> (jwhois), and since I have learnt the lesson of moving the debian
> directory in the CVS, I'm planning to add them as a separate module.
>
> My question, howe
14 matches
Mail list logo
