On Thu, 11 Dec 2003 20:30:57 -0200
"Leo \"Costela\" Antunes" <[EMAIL PROTECTED]> wrote:
> On Qui, 2003-12-11 at 20:00, Florian Zaehringer wrote:
> > Hi folks!
>
> Hi
>
Hi again!
> Read:
> /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
> (package debian-policy)
Thanks (also to everybo
On Thu, 11 Dec 2003 23:35:16 +0100
Frank Lichtenheld <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote:
> > So I wonder how I can do that? Is there some ChangeLog for the
> > Debian Policy? Does somebody know where I can find the right docs?
> > Or bet
On Fri, 12 Dec 2003 00:42:22 +
MJ Ray <[EMAIL PROTECTED]> wrote:
> On 2003-12-11 22:00:45 + Florian Zaehringer
> <[EMAIL PROTECTED]> wrote:
>
> > I am planing to adopt my first package (emelfm, orphaned). So I
> > checked what
> > needs to be done to equip myself for this task.
>
> Ha
Thanks for all the input! From this discussion I conclude that in my
package's case there is no call for db_input in postinst, so I just
commented out those calls and lintian/linda are happy :)
Maybe it would be useful to summarise the cases where you are pretty
forced to use db_input calls in pos
On Thu, 11 Dec 2003 20:30:57 -0200
"Leo \"Costela\" Antunes" <[EMAIL PROTECTED]> wrote:
> On Qui, 2003-12-11 at 20:00, Florian Zaehringer wrote:
> > Hi folks!
>
> Hi
>
Hi again!
> Read:
> /usr/share/doc/debian-policy/upgrading-checklist.txt.gz
> (package debian-policy)
Thanks (also to everybo
On Fri, 12 Dec 2003 00:42:22 +
MJ Ray <[EMAIL PROTECTED]> wrote:
> On 2003-12-11 22:00:45 + Florian Zaehringer
> <[EMAIL PROTECTED]> wrote:
>
> > I am planing to adopt my first package (emelfm, orphaned). So I
> > checked what
> > needs to be done to equip myself for this task.
>
> Ha
On Thu, 11 Dec 2003 23:35:16 +0100
Frank Lichtenheld <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote:
> > So I wonder how I can do that? Is there some ChangeLog for the
> > Debian Policy? Does somebody know where I can find the right docs?
> > Or bet
Thanks for all the input! From this discussion I conclude that in my
package's case there is no call for db_input in postinst, so I just
commented out those calls and lintian/linda are happy :)
Maybe it would be useful to summarise the cases where you are pretty
forced to use db_input calls in pos
On Fri, Dec 12, 2003 at 10:42:34AM -0800, Josh Lauricha wrote:
> On Fri 12/12/03 10:59, Jamin W. Collins wrote:
> > In this particular case it's a concern about not storing a DB admin
> > password in debconf yet still being able to properly remove a package
> > created DB if the user has requested
On Fri 12/12/03 10:59, Jamin W. Collins wrote:
> In this particular case it's a concern about not storing a DB admin
> password in debconf yet still being able to properly remove a package
> created DB if the user has requested the package do so on purge.
Perhaps a db user created on install with
On Fri, Dec 12, 2003 at 10:42:34AM -0800, Josh Lauricha wrote:
> On Fri 12/12/03 10:59, Jamin W. Collins wrote:
> > In this particular case it's a concern about not storing a DB admin
> > password in debconf yet still being able to properly remove a package
> > created DB if the user has requested
On Fri, Dec 12, 2003 at 10:00:16AM +, Colin Watson wrote:
> On Fri, Dec 12, 2003 at 10:42:10AM +0100, Frank K?ster wrote:
> >
> > I can't find it right now, but isn't it written somewhere that prompting
> > in postinst will be a no-no in future policy releases?
>
> It shouldn't be (I think yo
On Fri 12/12/03 10:59, Jamin W. Collins wrote:
> In this particular case it's a concern about not storing a DB admin
> password in debconf yet still being able to properly remove a package
> created DB if the user has requested the package do so on purge.
Perhaps a db user created on install with
On Fri, Dec 12, 2003 at 10:00:16AM +, Colin Watson wrote:
> On Fri, Dec 12, 2003 at 10:42:10AM +0100, Frank K?ster wrote:
> >
> > I can't find it right now, but isn't it written somewhere that prompting
> > in postinst will be a no-no in future policy releases?
>
> It shouldn't be (I think yo
On Fri, Dec 12, 2003 at 10:42:10AM +0100, Frank Küster wrote:
> "Jamin W. Collins" <[EMAIL PROTECTED]> schrieb:
> > On Thu, Dec 11, 2003 at 11:51:01PM +0100, Jeremy Lain? wrote:
> >> I can see how it is a Bad Thing to prompt the user for input both in
> >> postinst and in config, but the fact still
"Jamin W. Collins" <[EMAIL PROTECTED]> schrieb:
> On Thu, Dec 11, 2003 at 11:51:01PM +0100, Jeremy Lain? wrote:
>>
>> I can see how it is a Bad Thing to prompt the user for input both in
>> postinst and in config, but the fact still stands that it's the way
>> it's done in horde2, and I'm sure the
On Fri, Dec 12, 2003 at 10:42:10AM +0100, Frank Küster wrote:
> "Jamin W. Collins" <[EMAIL PROTECTED]> schrieb:
> > On Thu, Dec 11, 2003 at 11:51:01PM +0100, Jeremy Lain? wrote:
> >> I can see how it is a Bad Thing to prompt the user for input both in
> >> postinst and in config, but the fact still
"Jamin W. Collins" <[EMAIL PROTECTED]> schrieb:
> On Thu, Dec 11, 2003 at 11:51:01PM +0100, Jeremy Lain? wrote:
>>
>> I can see how it is a Bad Thing to prompt the user for input both in
>> postinst and in config, but the fact still stands that it's the way
>> it's done in horde2, and I'm sure the
On Thu, Dec 11, 2003 at 09:47:45PM -0800, David Braun wrote:
> On Thu, 2003-12-11 at 12:42, Matt Zimmerman wrote:
> > I would simply include the SQL dump under /usr/share and leave it to the
> > user where to import it. It's possible that they will want to create a new
> > database, or import it
On Thu, Dec 11, 2003 at 09:47:45PM -0800, David Braun wrote:
> On Thu, 2003-12-11 at 12:42, Matt Zimmerman wrote:
> > I would simply include the SQL dump under /usr/share and leave it to the
> > user where to import it. It's possible that they will want to create a new
> > database, or import it
On Thu, 2003-12-11 at 12:42, Matt Zimmerman wrote:
> I would simply include the SQL dump under /usr/share and leave it to the
> user where to import it. It's possible that they will want to create a new
> database, or import it into an existing one (perhaps even with different
> table names), or t
21 matches
Mail list logo
