Comments:

• Why must the sub-package be noarch? Are only bash and python supported?
• I don't like "fedora" in the macro names. What about EPEL versions of packages? Can they tie into the RHEL upgrade mechanism?

FPC discussed this a bit at the meeting. I can loosely sum up the general opinion as: this is mostly OK, but there are a few issues and questions.

• As above, why noarch?
• Why the fedora macro names? They appear to be unnecessary verbiage. We know this is Fedora, after all.
• The package names seem... very long. Why not just preupgrade-assistant-*?
• The use of mariadb in the example spec is needlessly complex as it makes it seem as if all of that additional macroization is somehow necessary. I'll go ahead and rewrite it to something generic.
• There doesn't seem to be any description anywhere of just what all of these random .sh, .py, .xml and .txt files do, what they're used for or where they come from. We're not saying that all needs to be in the guidelines, but I can't find that description anywhere.
• The lack of any example we can look at is problematic. It might answer the issue above. I looked at the mariadb package (since it's the example) but none of that appears to have been checked in.

Some more:

• "buildroor" thoughout changed to "buildroot".
• If the installed files are always going to be the same, why not a %{preupgrade_install} macro to match %{preupgrade_build}? Maybe %{preupgrade_prep} as well? I guess differing SOURCEn lists might be a problem there.

Replying to [comment:2 orion]:

Comments:

• Why must the sub-package be noarch? Are only bash and python supported?
  Supported scripts are bash, python, perl, javascript. But mainly bash and python. Therefore noarch.
  No C/C++ codes.
• I don't like "fedora" in the macro names. What about EPEL versions of packages? Can they tie into the RHEL upgrade mechanism?
  Like F22_23 instead of Fedora22_23? Why not.

What about to use just %{preupgrade_name} which refers to Fedora22_23
and %{preupgrade_dir} which referes to /usr/share/preupgrade/%{preupgrade_name}?

Replying to [comment:3 tibbs]:

FPC discussed this a bit at the meeting. I can loosely sum up the general opinion as: this is mostly OK, but there are a few issues and questions.

• As above, why noarch?
  Scripts can be bash, python, perl, javascript. Therefore noarch. Contents are stored in /usr/share/preupgrade/ directory where could be a conflict If contents are arch dependent.
• Why the fedora macro names? They appear to be unnecessary verbiage. We know this is Fedora, after all.
• The package names seem... very long. Why not just preupgrade-assistant-*?
  Yeah, it could be and seems to be better.
• The use of mariadb in the example spec is needlessly complex as it makes it seem as if all of that additional macroization is somehow necessary. I'll go ahead and rewrite it to something generic.
• There doesn't seem to be any description anywhere of just what all of these random .sh, .py, .xml and .txt files do, what they're used for or where they come from. We're not saying that all needs to be in the guidelines, but I can't find that description anywhere.
• The lack of any example we can look at is problematic. It might answer the issue above. I looked at the mariadb package (since it's the example) but none of that appears to have been checked in.

INI file description was added to the Draft page.

Bash and Python check script templates were added.

Thanks for updating SPEC file to foo.SPEC, though.

Replying to [comment:3 tibbs]:

FPC discussed this a bit at the meeting. I can loosely sum up the general opinion as: this is mostly OK, but there are a few issues and questions.

• As above, why noarch?
• Why the fedora macro names? They appear to be unnecessary verbiage. We know this is Fedora, after all.
• The package names seem... very long. Why not just preupgrade-assistant-*?
  Corrected.
• The use of mariadb in the example spec is needlessly complex as it makes it seem as if all of that additional macroization is somehow necessary. I'll go ahead and rewrite it to something generic.
• There doesn't seem to be any description anywhere of just what all of these random .sh, .py, .xml and .txt files do, what they're used for or where they come from. We're not saying that all needs to be in the guidelines, but I can't find that description anywhere.
• The lack of any example we can look at is problematic. It might answer the issue above. I looked at the mariadb package (since it's the example) but none of that appears to have been checked in.

Replying to [comment:4 tibbs]:

Some more:

• "buildroor" thoughout changed to "buildroot".
  Thanks for correction.
• If the installed files are always going to be the same, why not a %{preupgrade_install} macro to match %{preupgrade_build}? Maybe %{preupgrade_prep} as well? I guess differing SOURCEn lists might be a problem there.

%{preupgrade_build} command creates a XML file from INI file delivered by maintainer but it is the same.
But it can be changed to %{preupgrade_prep} which really prepares XML file for preupgrade-assistant usage. We can change that to %{preupgrade_prep}.

I changed that.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-02-19/fpc.2015-02-19-17.00.txt):

• 495 Proposal: Package Guidelines: PreupgradeAssistant contents

  
  packages (geppetto, 17:32:26)
• LINK: https://fedorahosted.org/fpc/ticket/495 (geppetto, 17:32:30)
• ACTION: PreupgradeAssistant contents packages (+1:6, 0:0, -1:0)
  (geppetto, 17:57:49)
• LINK: https://github.com/phracek/preupgrade-assistant (tibbs|w,
  17:57:55)

Announcement text:

Guidelines for Preupgrade Assistant packages have been added.
* https://fedoraproject.org/wiki/Packaging:PreupgradeAssistant
* https://fedorahosted.org/fpc/ticket/495