Rahul Sundaram wrote:
On Mon, Jan 10, 2011 at 11:47 PM, susmit shannigrahi
thinklinux@gmail.com 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:
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, it
ss == susmit shannigrahi thinklinux@gmail.com 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
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 sure
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 no
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
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
--
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.
Plus,
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.
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 to be
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
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
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, 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 whether to
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
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
On Sat, Jan 8, 2011 at 2:18 PM, Kevin Kofler kevin.kof...@chello.at 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
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 simply
--
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 not yet
JC == Jon Ciesla l...@jcomserv.net 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
--
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 l...@jcomserv.net 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
21 matches
Mail list logo
