Re: Question regarding RPM packaging of interactive software.
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: 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 should be part of the packaging guidelines. Rahul I was merely giving advice before rushing off to bed. I agree that of not codified, it should be so. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 should be part of the packaging guidelines. Not sure where it should go inside packaging guidelines. Can anyone else please do that? -- Regards, Susmit. = http://www.fedoraproject.org/wiki/user:susmit = -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 consideration; just create your draft somewhere on the wiki (your personal space is a good place) and open a ticket at https://fedorahosted.org/fpc/ including the URL of your draft. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 if the database is available at RPM install/upgrade time. Plus, the consquences of a failed or interrupted RPM transaction on the DB could be. . interesting. So, in short, don't do it, and but if no one can find a citation in the guidelines someone ought to write a draft, for that way lies madness. :) Thanks for your help. I shall take these to upstream. 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 problem, as there's no database operation to handle. This is how all mature, popular apps that rely on databases work. For instance, when you install Wordpress, you then go through a short 'setup' process which prompts you to manually create the necessary databases and configure Wordpress to be able to access them. Normally, when the software is updated, on the next run it should automatically make any necessary changes to its own database (since obviously it now has the required access privileges). If there is a major update that requires changes to the database that cannot be automated, then again, these should be documented for the user to carry out, no crazy 'overwrite or no' interactive options during package install. Your next step should be to outline this to upstream, and show examples of widely-used database apps such as Wordpress and MythTV and so on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 problem, as there's no database operation to handle. This is how all mature, popular apps that rely on databases work. For instance, when you install Wordpress, you then go through a short 'setup' process which prompts you to manually create the necessary databases and configure Wordpress to be able to access them. Normally, when the software is updated, on the next run it should automatically make any necessary changes to its own database (since obviously it now has the required access privileges). If there is a major update that requires changes to the database that cannot be automated, then again, these should be documented for the user to carry out, no crazy 'overwrite or no' interactive options during package install. Your next step should be to outline this to upstream, and show examples of widely-used database apps such as Wordpress and MythTV and so on. 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 -- Regards, Susmit. = http://www.fedoraproject.org/wiki/user:susmit = -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 information without any references from anywhere else is useful. If this needs to be documented, it should be part of the packaging guidelines. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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, the consquences of a failed or interrupted RPM transaction on the DB could be. . interesting. So, in short, don't do it, and but if no one can find a citation in the guidelines someone ought to write a draft, for that way lies madness. :) Thanks for your help. I shall take these to upstream. -- Regards, Susmit. = http://www.fedoraproject.org/wiki/user:susmit = -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 patched and made non-interactive? 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 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 tried), it simply overwrites the database. In this process, it asks the user whether to overwrite the DB or not. My initial thought was to backup the database somewhere and continue. However, when I asked upstream, they replied that there is no easy way to restore these databases. Thanks. -- Regards, Susmit. = http://www.fedoraproject.org/wiki/user:susmit = -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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-interactive? yes - interactivity during install is not allowed. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 postgres database for storing data. For subsequent installations (if tried), it simply overwrites the database. In this process, it asks the user whether to overwrite the DB or not. My initial thought was to backup the database somewhere and continue. However, when I asked upstream, they replied that there is no easy way to restore these databases. Has it been packaged for other distributions? If so, what have they done about this problem? We simply cannot ask questions during installation. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 overwrite the DB or not. My initial thought was to backup the database somewhere and continue. However, when I asked upstream, they replied that there is no easy way to restore these databases. But isn't creating a PostgreSQL database at RPM install possible at all? How can the RPM know the access details etc.? Isn't there a packaging guideline that forbids this in all cases? -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 before inclusion. If that's all the user interaction required, no need to search further. Since RPM has no interactive user input support, the only way would be scripting it using automation tools like expect or pexpect (if you're a pythonista) but handling interactive user input is quite buggy (how do you handle translated strings ?, what happens if upstream modifies its user interface ? etc ...) My initial thought was to backup the database somewhere and continue. Not acceptable from an user POV. best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 software not work? Correct, it exits the installation. -- Regards, Susmit. = http://www.fedoraproject.org/wiki/user:susmit = -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 overwrites the database. In this process, it asks the user whether to overwrite the DB or not. My initial thought was to backup the database somewhere and continue. However, when I asked upstream, they replied that there is no easy way to restore these databases. But isn't creating a PostgreSQL database at RPM install possible at all? How can the RPM know the access details etc.? Isn't there a packaging guideline that forbids this in all cases? There's no specific guideline but overwriting the database would almost certainly fall under the reviewers good judgement to stop. If there's some conflict about that being common sense, the FPC can certainly take a draft to be more specific about it. -Toshio pgpg4SpUZSVZh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
-- 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 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 overwrite the DB or not. My initial thought was to backup the database somewhere and continue. However, when I asked upstream, they replied that there is no easy way to restore these databases. But isn't creating a PostgreSQL database at RPM install possible at all? How can the RPM know the access details etc.? Isn't there a packaging guideline that forbids this in all cases? There's no specific guideline but overwriting the database would almost certainly fall under the reviewers good judgement to stop. If there's some conflict about that being common sense, the FPC can certainly take a draft to be more specific about it. -Toshio 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, the consquences of a failed or interrupted RPM transaction on the DB could be. . interesting. So, in short, don't do it, and but if no one can find a citation in the guidelines someone ought to write a draft, for that way lies madness. :) -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
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 an rpm can do on its own; for mysql, at least, rpm certainly won't have any way at all to get at local administrative password. And of course databases can be on remote machines, so such packages rarely have dependencies on the actual database server anyway (just the client libraries) and certainly no way to figure out where the remote server is or how to access it. Now, sqlite would be a different matter. It would still be terribly antisocial for a package to wipe out existing data on an upgrade, but creating and managing sqlite databases is something that could be done by the package (although I'd still think that's better left for runtime). - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding RPM packaging of interactive software.
-- 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 the JC database is available at RPM install/upgrade time. It's pretty simple. Creating databases isn't generally something that an rpm can do on its own; for mysql, at least, rpm certainly won't have any way at all to get at local administrative password. And of course databases can be on remote machines, so such packages rarely have dependencies on the actual database server anyway (just the client libraries) and certainly no way to figure out where the remote server is or how to access it. Right, and on top of that, there are many applications that can use multiple types of database backends. Bacula, for example, can use MySQL, PostgreSQL, or sqlite. While finding out which it's using can be done by looking at the config files, do we really want to teach RPM to read hundreds of different types of config files? Plus the dependancies on client libs? Now, sqlite would be a different matter. It would still be terribly antisocial for a package to wipe out existing data on an upgrade, but creating and managing sqlite databases is something that could be done by the package (although I'd still think that's better left for runtime). Agreed, theoretically possible, but inadvisable. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
