https://bugzilla.redhat.com/show_bug.cgi?id=995045 --- Comment #6 from Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> --- (In reply to Marek Goldmann from comment #5) > > Problem 2: > > It is a good idea to check if all JARs were replaced by symlinks > > and faild the build if not. Not doing so may have a secutity > > implications. For example if some JAR is not replaced with symlink > > and it has a security bug, updating the dependency wouldn't be enough > > -- wildfly would be left with old, vulnerable version of dependency. > > I'm removing the jars that were not replaced by symlinking later in the spec > file. After that I'm manually linking these exceptions. After the build I > check if there are some missing symlinks or if the symlinks are broken. Currently all JARs are properly replaced by symlinks, but in future (for example after wildfly update or change to some other packages) some JARs may be left not replaced. Do you want to manually verify if JARs are replaced properly with every rebuild of wildfly? It's much safer (and easier) if you just add a single line verifying if all JARs were replaced. > > Problem 3: > > %preun scriplet calls "rm -rf" without checking what is being removed. > > Users could theoretically replace these symlinks with directory and put > > some data there. Uninstalling wildfly could cause data loss. > > Is this an issue? This directory is created by the wildfly package and > shouldn't be used by anyone else, never. If you have a better idea how could > I symlink it - please share it with me. Packages should not remove files not owned or created by them. You should check if the file you want to remove is a symlink and then try to remove it, for example: [ -L filename ] && rm -f filename Using wildcards or removing whole directories is best avoided. > > Problem 4: > > Some directories are created as linux-x86_64 and linux-i686. > > What about ARM? it's also a primary architecture. > > Upstream does not ship any ARM binaries. These directories exist in the > upstream binary package: > > linux-i686/ linux-x86_64/ macosx-i686/ macosx-x86_64/ win-i686/ > win-x86_64/ > > I'm not sure if upstream even considered running on ARM. I need to consirm > it and find the proper directory structure if it should be linked on ARM too. Fedora packagers should make every effort to support all primary architectures [1]. As ARM will be a primary architecture I would strongly recommend trying to support it too, even if it's not supported by upstream. [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BQRUxAoyUR&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review