> "ss" == susmit shannigrahi writes:
ss> Not sure where it should go inside packaging guidelines. Can anyone
ss> else please do that?
Packaging guidelines are modified by the packaging committee and are not
generally editable. You are welcome to submit a draft for
consideration; just create
>> Given the size of the wiki, I am surprised that there is no
>> documentation in this regard.
>> I have started one: https://fedoraproject.org/wiki/Packaging/FAQ
>
> I don't think spreading out the information without any references from
> anywhere else is useful. If this needs to be documented,
Rahul Sundaram wrote:
>
>
> On Mon, Jan 10, 2011 at 11:47 PM, susmit shannigrahi
> mailto:thinklinux@gmail.com>>
>
>
> Nice, thanks.
> Given the size of the wiki, I am surprised that there is no
> documentation in this regard.
> I have started one: https://fedoraproject.org/wi
On Mon, Jan 10, 2011 at 11:47 PM, susmit shannigrahi <
thinklinux@gmail.com>
>
>
> Nice, thanks.
> Given the size of the wiki, I am surprised that there is no
> documentation in this regard.
> I have started one: https://fedoraproject.org/wiki/Packaging/FAQ
I don't think spreading out the inf
> I think, just in case it's not clear, that the typical way this should
> be handled is that on installation the software should not create the
> necessary database; instead the creation process should be documented
> for the user to complete manually. So when the software is packaged,
> there's n
On Sun, 2011-01-09 at 11:37 -0700, susmit shannigrahi wrote:
> > My understanding was that we never touch databases in RPMs, period. We
> > don't create, modify, update, or remove. I can't recall at the moment
> > where this stems from, but the rationale, as I recall, was that we can
> > never be
> My understanding was that we never touch databases in RPMs, period. We
> don't create, modify, update, or remove. I can't recall at the moment
> where this stems from, but the rationale, as I recall, was that we can
> never be sure if the database is available at RPM install/upgrade time.
> Plu
susmit shannigrahi wrote:
> Correct, it exits the installation.
Then the software is broken and cannot reasonably be packaged at all.
Migrating data on upgrades ought to be automatic. Having the "options" of
"overwrite database" or "abort installation" is entirely useless.
Kevin Kofler
--
in your fear, seek only peace
in your fear, speak only love
-d. bowie
On Sat, 8 Jan 2011, Jason L Tibbitts III wrote:
>> "JC" == Jon Ciesla writes:
>
> JC> I can't recall at the moment where this stems from, but the
> JC> rationale, as I recall, was that we can never be sure if the
> J
> "JC" == Jon Ciesla writes:
JC> I can't recall at the moment where this stems from, but the
JC> rationale, as I recall, was that we can never be sure if the
JC> database is available at RPM install/upgrade time.
It's pretty simple. Creating databases isn't generally something that
an rpm c
--
in your fear, seek only peace
in your fera, speak only love
-d. bowie
On Sat, 8 Jan 2011, Toshio Kuratomi wrote:
> On Sat, Jan 08, 2011 at 05:57:52PM +0100, Jos Vos wrote:
>> On Sat, Jan 08, 2011 at 09:31:07AM -0700, susmit shannigrahi wrote:
>>
>>> This software (gnumed-server, which is no
On Sat, Jan 08, 2011 at 05:57:52PM +0100, Jos Vos wrote:
> On Sat, Jan 08, 2011 at 09:31:07AM -0700, susmit shannigrahi wrote:
>
> > This software (gnumed-server, which is not yet in bugzilla) uses a
> > postgres database for storing data.
> >
> > For subsequent installations (if tried), it simpl
On Sat, Jan 8, 2011 at 2:18 PM, Kevin Kofler wrote:
> susmit shannigrahi wrote:
>> For subsequent installations (if tried), it simply overwrites the
>> database. In this process, it asks the user whether to overwrite the
>> DB or not.
>
> And what happens if you say "no"? Does the software not wor
susmit shannigrahi wrote:
> For subsequent installations (if tried), it simply overwrites the
> database. In this process, it asks the user whether to overwrite the
> DB or not.
And what happens if you say "no"? Does the software not work?
Kevin Kofler
--
devel mailing list
devel@lists.
Le 08/01/2011 17:31, susmit shannigrahi a écrit :
>
> For subsequent installations (if tried), it simply overwrites the
> database. In this process, it asks the user whether to overwrite the
> DB or not.
This is plain stupid to overwrite the database by default, this MUST be
fixed by upstream be
On Sat, Jan 08, 2011 at 09:31:07AM -0700, susmit shannigrahi wrote:
> This software (gnumed-server, which is not yet in bugzilla) uses a
> postgres database for storing data.
>
> For subsequent installations (if tried), it simply overwrites the
> database. In this process, it asks the user whethe
On Sun, Jan 9, 2011 at 12:31 AM, susmit shannigrahi wrote:
> > Yes but you are better off explaining what the specifically requires user
> > interaction and we can potentially suggest good ways of handling it to
> > upstream
>
> This software (gnumed-server, which is not yet in bugzilla) uses a
>
On Sat, 2011-01-08 at 09:14 -0700, susmit shannigrahi wrote:
> Hi,
>
> Sorry if this has been discussed before, but I can not find much about this.
>
> What is Fedora's policy regarding RPM packaging of software that needs
> user interaction during installation? Is it to be patched and made
> non
> Yes but you are better off explaining what the specifically requires user
> interaction and we can potentially suggest good ways of handling it to
> upstream
This software (gnumed-server, which is not yet in bugzilla) uses a
postgres database for storing data.
For subsequent installations (if t
On Sun, Jan 9, 2011 at 12:14 AM, susmit shannigrahi <
thinklinux@gmail.com> wrote:
> Hi,
>
> Sorry if this has been discussed before, but I can not find much about
> this.
>
> What is Fedora's policy regarding RPM packaging of software that needs
> user interaction during installation? Is it t
Hi,
Sorry if this has been discussed before, but I can not find much about this.
What is Fedora's policy regarding RPM packaging of software that needs
user interaction during installation? Is it to be patched and made
non-interactive?
Thanks.
--
Regards,
Susmit.
=
21 matches
Mail list logo
