Bug 752169 - Review Request: zukitwo - Themes for GTK+2, GTK+3, Metacity, GNOME Shell and Xfwm4
Summary: Review Request: zukitwo - Themes for GTK+2, GTK+3, Metacity, GNOME Shell and ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Tim Lauridsen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-08 17:55 UTC by Mattia M.
Modified: 2012-08-05 07:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-21 07:13:29 UTC
Type: ---
tla: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Mattia M. 2011-11-08 17:55:04 UTC
Spec URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo/gnome-shell-theme-zukitwo.spec

SRPM URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo/gnome-shell-theme-zukitwo-0-1.d3df2ot.fc16.src.rpm

Description:
The Zukitwo theme for Gnome Shell, created by lassekongo83.

This is the second package I submit for review (the first one, https://bugzilla.redhat.com/show_bug.cgi?id=751537 , was rejected due to legal reasons).
Thus, I'm still seeking a sponsor.

Rpmlint , executed on both the .spec and the .rpm files, returns neither errors nor warnings.
I was a bit dubious about the entries "Version" and "Release" of the .spec file. I hope I've done the right thing in including the alphanumeric tag used by DeviantArt in the entry "Release".

Comment 1 Tim Lauridsen 2011-11-10 18:39:11 UTC
I will the review the package, but someone else needs to sponsor you.

Some initial comments.

Use 3.2 as version, because this is a gnome-3.2 theme
No need to add the deviantart tag id in release.

no need to require on gnome-tweak-tool, it is not a hard requirement.

Maybe splitting the gnome-shell theme and the gtk themes into separate sub packages would be a good idea.
You should be able to use the gnome-shell theme without the gtk themes

Let me know what you think

Comment 2 Mattia M. 2011-11-11 09:51:53 UTC
(In reply to comment #1)
> I will the review the package, but someone else needs to sponsor you.


Thank you very much!
 

> Some initial comments.
> 
> Use 3.2 as version, because this is a gnome-3.2 theme
> No need to add the deviantart tag id in release.
> 
> no need to require on gnome-tweak-tool, it is not a hard requirement.


Done.
 

> Maybe splitting the gnome-shell theme and the gtk themes into separate sub
> packages would be a good idea.
> You should be able to use the gnome-shell theme without the gtk themes
> 
> Let me know what you think


In my opinion, having an only package would be better, because
* the GTK themes and the Gnome Shell theme have been created explicitly to be used together;
* anyway, one can still choose to apply the GTK themes or the Gnome Shell theme alone through Gnome Tweak Tool, if he prefers.
But this is only a beginner's point of view. If other reasons exist to prefer creating separate subpackages, please let me know.

Here are the new spec and SRPM:

Spec URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo_2/gnome-shell-theme-zukitwo.spec

SRPM URL: http://dl.dropbox.com/u/39458594/Fedora%20packages/gnome-shell-theme-zukitwo_2/gnome-shell-theme-zukitwo-3.2-1.fc16.src.rpm

Comment 3 Tim Lauridsen 2011-11-28 17:52:51 UTC
Package Review
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated



==== Generic ====
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported architecture.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
     Note: Unless packager wants to package for EPEL5 this is fine
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: Note: defattr macros not found. They would be needed for EPEL5
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf would be needed if support for EPEL5 is required
[x]: MUST If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST Package consistently uses macros (instead of hard-coded directory
     names).
[x]: MUST Package meets the Packaging Guidelines.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generates any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint output is silent.

rpmlint gnome-shell-theme-zukitwo-3.2-1.fc17.src.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


rpmlint gnome-shell-theme-zukitwo-3.2-1.fc17.noarch.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
/home/tim/udv/work/FedoraReview/src/752169/zukitwo_by_lassekongo83-d3df2ot.zip :
  MD5SUM this package     : 9b03ca87116cf368de5a94b9573a3fd1
  MD5SUM upstream package : 9b03ca87116cf368de5a94b9573a3fd1

[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: MUST Package contains a SysV-style init script if in need of one.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[x]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: SHOULD Package functions as described.
[x]: SHOULD Package does not include license text files separate from
     upstream.
[x]: SHOULD SourceX is a working URL.
[!]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[?]: SHOULD Package should compile and build into binary rpms on all supported
     architectures.
[-]: SHOULD %check is present and all tests pass.
[x]: SHOULD Packages should try to preserve timestamps of original installed
     files.
[x]: SHOULD Spec use %global instead of %define.

Comment 4 Tim Lauridsen 2011-11-28 17:54:33 UTC
APPROVED

You should add something to description about the package also is containing gtk-themes and not just a shell theme

Comment 6 Mattia M. 2011-12-06 15:07:29 UTC
(In reply to comment #4)

> You should add something to description about the package also is containing
> gtk-themes and not just a shell theme

Done in the latest version of the package (see Comment 5).

Comment 7 Mohamed El Morabity 2011-12-06 15:55:19 UTC
(In reply to comment #2)
> In my opinion, having an only package would be better, because
> * the GTK themes and the Gnome Shell theme have been created explicitly to be
> used together;
> * anyway, one can still choose to apply the GTK themes or the Gnome Shell theme
> alone through Gnome Tweak Tool, if he prefers.
> But this is only a beginner's point of view. If other reasons exist to prefer
> creating separate subpackages, please let me know.
You should *really* split this package, as justified here:
   https://bugzilla.redhat.com/show_bug.cgi?id=744952#c5
The gtk2/gtk3/metacity theme can be used independently each other, and outside GNOME.
You should also rename your SRPM name, as explained here:
   https://bugzilla.redhat.com/show_bug.cgi?id=744952#c8

Comment 8 Tim Lauridsen 2011-12-09 10:14:34 UTC
(In reply to comment #7)
> (In reply to comment #2)
> > In my opinion, having an only package would be better, because
> > * the GTK themes and the Gnome Shell theme have been created explicitly to be
> > used together;
> > * anyway, one can still choose to apply the GTK themes or the Gnome Shell theme
> > alone through Gnome Tweak Tool, if he prefers.
> > But this is only a beginner's point of view. If other reasons exist to prefer
> > creating separate subpackages, please let me know.
> You should *really* split this package, as justified here:
>    https://bugzilla.redhat.com/show_bug.cgi?id=744952#c5
> The gtk2/gtk3/metacity theme can be used independently each other, and outside
> GNOME.
> You should also rename your SRPM name, as explained here:
>    https://bugzilla.redhat.com/show_bug.cgi?id=744952#c8

I agree, you split the gtk parts up in sub packages and let the gnome3 theme require them, then it will be possible to use them outside gnome

Comment 9 Mohamed El Morabity 2011-12-09 10:43:43 UTC
This is an example of how the splitting can be achieved:
   http://melmorabity.fedorapeople.org/packages/zukitwo/zukitwo.spec
By the way, you should *really* ask uipstream to set versions on its themes archive. You can't track new versions of the theme otherwise.

Comment 10 Tim Lauridsen 2011-12-10 08:50:59 UTC
(In reply to comment #9)
> This is an example of how the splitting can be achieved:
>    http://melmorabity.fedorapeople.org/packages/zukitwo/zukitwo.spec
> By the way, you should *really* ask uipstream to set versions on its themes
> archive. You can't track new versions of the theme otherwise.

Look good to me.

The versioning is a problem with most deviantart stuff, they just upload a zip with the latest stuff, no versioning at all :(

Comment 11 Mohamed El Morabity 2011-12-10 09:02:09 UTC
(In reply to comment #10)
> The versioning is a problem with most deviantart stuff, they just upload a zip
> with the latest stuff, no versioning at all :(
In a such a case, the timestamp of the archive should be used as a version; this should be here 20111205, for example.

Comment 12 Mattia M. 2011-12-12 15:11:17 UTC
(In reply to comment #9)
> This is an example of how the splitting can be achieved:
>    http://melmorabity.fedorapeople.org/packages/zukitwo/zukitwo.spec

(In reply to comment #11)
> In a such a case, the timestamp of the archive should be used as a version;
> this should be here 20111205, for example.

Thank you, Tim and Mohamed.
Here's the new version of the package, corrected according to your valuable suggestions:

Spec URL: http://db.tt/NHscmjFS

SRPM URL: http://db.tt/wf9g2TAC

By the way, since the name of the package has changed, should I file a new review request or can I go on with this one?

Comment 13 Mohamed El Morabity 2011-12-12 15:19:54 UTC
(In reply to comment #12)
> By the way, since the name of the package has changed, should I file a new
> review request or can I go on with this one?
You can go on with this one, you just have to edit the title of the bug report to reflect the new name of the .spec file.

Comment 14 Tim Lauridsen 2011-12-20 09:00:40 UTC
Look good to me, so the package is still APPROVED.

Comment 15 Mattia M. 2012-03-23 07:55:36 UTC
Packages updated to the 2011.12.29 version of the theme:

Spec URL: http://db.tt/xOZgxcBz

SRPM URL: http://db.tt/XoDkNQnb

_________________________________________________________________________________

For those who want to install the themes, here are the RPM packages for Fedora 16:

GTK+2 theme: http://db.tt/vzf2JnoU
GTK+3 theme: http://db.tt/ast9bEmg
Metacity theme: http://db.tt/MRH5FyzA
GNOME Shell theme: http://db.tt/UKtzafdQ
Xfwm4 theme: http://db.tt/QMxORubq

Comment 16 Michel Alexandre Salim 2012-04-24 04:56:00 UTC
Tim, are you still happy with the package as updated? I can sponsor Mattia if nobody else has done so.

Mattia, just in case, please confirm that you're still interested, as it's been a month.

Comment 17 Tim Lauridsen 2012-04-24 12:35:16 UTC
@Michel.

Still looks fine to me, so please sponsor

Comment 18 Mattia M. 2012-04-25 06:47:00 UTC
(In reply to comment #16)
> Tim, are you still happy with the package as updated? I can sponsor Mattia if
> nobody else has done so.
> 
> Mattia, just in case, please confirm that you're still interested, as it's been
> a month.

Sure I'm interested.

(In reply to comment #17)
> @Michel.
> 
> Still looks fine to me, so please sponsor

Thank you both.

Comment 19 Mattia M. 2012-04-26 22:47:53 UTC
Packages updated to the 2012.04.26 version of the theme:

Spec URL: http://db.tt/w7EhTdZj

SRPM URL: http://db.tt/F6hkNBs1

NOTE (IMPORTANT): From now on, this theme will be compatible only with GNOME 3.4 (i.e. Fedora 17). The latest compatible with GNOME 3.2 (i.e. Fedora 16) is version 2011.12.29, linked in comment #15.
_________________________________________________________________________________

For those who want to install the theme, here are the RPM packages for Fedora
17:

GTK+2 theme: http://db.tt/rezvGDVG
GTK+3 theme: http://db.tt/ljyudPHP
Metacity theme: http://db.tt/1VJFCQRQ
GNOME Shell theme: http://db.tt/4AyjHKKe
Xfwm4 theme: http://db.tt/TkSJAK8f

Comment 20 Mattia M. 2012-04-30 07:24:12 UTC
Packages updated to the 2012.04.29 version of the theme:

Spec URL: http://db.tt/GJvcxURB

SRPM URL: http://db.tt/Jc4kx5zG
_________________________________________________________________________________

RPM packages for Fedora 17:

GTK+2 theme: http://db.tt/m5zJLrya
GTK+3 theme: http://db.tt/m5zJLrya
Metacity theme: http://db.tt/9lEZvIHE
GNOME Shell theme: http://db.tt/rz6Hj8GR
Xfwm4 theme: http://db.tt/yE954TWa

Comment 21 Mattia M. 2012-04-30 07:28:52 UTC
The link to the RPM package of the GTK+3 theme in comment #20 is wrong. Sorry.
Here's the right one:

GTK+3 theme: http://db.tt/Er9JqwEw

Comment 22 Michel Alexandre Salim 2012-05-03 10:25:24 UTC
Just tested the F17 builds and they look fine. Mattia, what's your FAS username?

(note that you can get space on fedorapeople.org -- see http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org -- and put your review packages there)

Comment 23 Mattia M. 2012-05-04 06:21:18 UTC
(In reply to comment #22)
> Mattia, what's your FAS username?

My user name on the Fedora Account System is "odysseus".
Thank you!

Comment 24 Michel Alexandre Salim 2012-05-04 12:41:26 UTC
OK, you're sponsored. Feel free to request a repository for your package now -- and don't hesitate to email if you have any packaging question. Cheers (and thanks for packaging this, my Eclipse, Emacs, and Qt programs finally fit into my desktop)

Comment 25 Mattia M. 2012-05-04 12:55:17 UTC
(In reply to comment #24)
> OK, you're sponsored. Feel free to request a repository for your package now --
> and don't hesitate to email if you have any packaging question.

Thank you very much!

> Cheers (and thanks for packaging this, my Eclipse, Emacs, and Qt programs 
> finally fit into my desktop)

You're welcome.

Comment 26 Mattia M. 2012-05-05 08:21:57 UTC
New Package SCM Request
=======================
Package Name: zukitwo
Short Description: The Zukitwo themes for GTK+2, GTK+3, Metacity, GNOME Shell and Xfwm4, created by lassekongo83.
Owners: odysseus
Branches: f17
InitialCC:

Comment 27 Mattia M. 2012-05-05 10:46:55 UTC
I've been sponsored for almost a day, but I can't change the "fedora‑cvs" flag to "?" yet, as needed to request a repository for this package.
Any suggestions?
_________________________________________________________________________________

Since I haven't been able to set up everything so far yet, I still link the latest (i.e. 2012.05.03) version of Zukitwo (for Gnome 3.4/Fedora 17 only!) here:

Spec URL: http://db.tt/XQQBqjk6
SRPM URL: http://db.tt/L4XA6LxK

RPM packages for Fedora 17:

GTK+2 theme: http://db.tt/2AAOvVpc
GTK+3 theme: http://db.tt/J65iTN4C
Metacity theme: http://db.tt/nPSn6NqR
GNOME Shell theme: http://db.tt/hDGlZey4
Xfwm4 theme: http://db.tt/vlIU8MGi

Enjoy!

Comment 28 Michel Alexandre Salim 2012-05-05 15:00:44 UTC
(In reply to comment #27)
> I've been sponsored for almost a day, but I can't change the "fedora‑cvs" flag
> to "?" yet, as needed to request a repository for this package.
> Any suggestions?

Hi Mattia,

Looks like you changed your Bugzilla email address to your @fedoraproject.org alias -- this is not allowed, and is probably why you can't change the flags. 

You need to have the same address listed in FAS (currently mattiameneguzzo@gmail.com) as the address you use for Bugzilla. Let me know if that still doesn't work (probably give it a couple of hours to settle).

Comment 29 Mattia M. 2012-05-05 17:17:44 UTC
(In reply to comment #28)
> Hi Mattia,
> 
> Looks like you changed your Bugzilla email address to your @fedoraproject.org
> alias -- this is not allowed, and is probably why you can't change the flags. 
> 
> You need to have the same address listed in FAS (currently
> mattiameneguzzo@gmail.com) as the address you use for Bugzilla.

The problem is it looks like I cannot change my email address again: "Preferences"->"Name and password" shows me the "Confirmed email address" only (i.e. the "@fedoraproject.org" one) but no entry to enter a new one.

Comment 30 Michel Alexandre Salim 2012-05-06 02:05:42 UTC
Odd, this is what I get:

https://bugzilla.redhat.com/userprefs.cgi?tab=account


Name and Password

Please enter your existing password to confirm account changes.
Password:	
New password:	
Confirm new password:	
Your real name (optional, but encouraged):	
New email address:	

So you basically managed to change your email from hotmail -> fp.o with this form, but now it's no longer let you change it again... hm. I'll ask one of the admins

Comment 31 Mattia M. 2012-05-06 05:55:08 UTC
(In reply to comment #30)
> Odd, this is what I get:
> 
> https://bugzilla.redhat.com/userprefs.cgi?tab=account
> 
> 
> Name and Password
> 
> Please enter your existing password to confirm account changes.
> Password: 
> New password: 
> Confirm new password: 
> Your real name (optional, but encouraged): 
> New email address: 
> 
> So you basically managed to change your email from hotmail -> fp.o with this
> form, but now it's no longer let you change it again... hm. I'll ask one of the
> admins

Yes, exact. This is the "Name and Password" tab as it appears now: http://db.tt/gLyXcMdY
Maybe there's a minimum time interval between two consecutive changes of email address, but this is only a guess.
Thanks for your help.

Comment 32 Michel Alexandre Salim 2012-05-06 13:57:06 UTC
It does say "Completion date: 2012-05-08 10:49:36 CEST" -- so I'm guessing you'd have to wait till then :)

Comment 33 Mattia M. 2012-05-06 19:07:28 UTC
I didn't notice that - I don't know why. Sorry! :-(

Comment 34 Toshio Kuratomi 2012-05-07 16:05:44 UTC
Hey Mattia, I could change your login email address in bugzilla to the email address you have listed in the Fedora Account System (since odysseus@fp.o just forwards there).  Would that work for you?

Comment 35 Mattia M. 2012-05-07 21:16:07 UTC
(In reply to comment #34)
> Hey Mattia, I could change your login email address in bugzilla to the email
> address you have listed in the Fedora Account System (since odysseus@fp.o just
> forwards there).  Would that work for you?

If the reason for me not being able to set the "fedora-cvs" flag is my current login email address, please proceed. Thanks in advance.

Comment 36 Mattia M. 2012-05-08 07:27:00 UTC
OK, I've been able to change my login email address and to set the "fedora-cvs" flag.

For the new package SCM request, go to comment #26.

Comment 37 Michel Alexandre Salim 2012-05-08 10:39:19 UTC
The SCM request is processed automatically, I believe -- could you just comment again with the request? I'm not sure it works if the request is in a preceding comment. Thanks :)

Comment 38 Mattia M. 2012-05-08 10:50:30 UTC
New Package SCM Request
=======================
Package Name: zukitwo
Short Description: The Zukitwo themes for GTK+2, GTK+3, Metacity, GNOME Shell and Xfwm4, created by lassekongo83.
Owners: odysseus
Branches: f17
InitialCC:

Comment 39 Gwyn Ciesla 2012-05-08 12:32:57 UTC
Git done (by process-git-requests).

Comment 40 Fedora Update System 2012-05-12 08:19:18 UTC
zukitwo-20120511-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120511-1.fc17

Comment 41 Mattia M. 2012-05-12 09:07:44 UTC
The package for the latest (i.e. 2012.05.11) version of Zukitwo is in Bodhi (see comment #40). Please try it, if you wish.

I seize this opportunity to warmly thank you all for your precious support!

Comment 42 Fedora Update System 2012-05-12 19:45:30 UTC
zukitwo-20120511-1.fc17 has been pushed to the Fedora 17 testing repository.

Comment 43 Fedora Update System 2012-05-19 07:45:12 UTC
zukitwo-20120516-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120516-1.fc17

Comment 44 Artyom Kunyov 2012-05-19 15:50:42 UTC
I think default font in gnome-shell.css should be changed to something else, since "ubuntu" fonts are not available in Fedora repos.

Comment 45 Mattia M. 2012-05-21 07:13:29 UTC
I'm closing this review request, as stated in https://fedoraproject.org/wiki/Package_Review_Process#Contributor .

Thanks again to everyone who helped me! :-)

Comment 46 Fedora Update System 2012-05-25 02:47:55 UTC
zukitwo-20120523-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120523-1.fc17

Comment 47 Fedora Update System 2012-05-26 08:30:55 UTC
zukitwo-20120526-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120526-1.fc17

Comment 48 Fedora Update System 2012-06-03 10:29:27 UTC
zukitwo-20120602-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120602-1.fc17

Comment 49 Fedora Update System 2012-06-05 20:09:06 UTC
zukitwo-20120602-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120602-2.fc17

Comment 50 Fedora Update System 2012-06-09 08:25:48 UTC
zukitwo-20120607-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zukitwo-20120607-1.fc17

Comment 51 Fedora Update System 2012-06-17 22:26:40 UTC
zukitwo-20120607-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 52 Mattia M. 2012-07-12 06:32:15 UTC
I've been told that, when multiple subpackages share common directories/files, it's better to define a "*-common" subpackage which owns them.

As for Zukitwo, the situation is a bit complicated:

- all subpackages share documentation files and a common main directory: "/usr/share/themes/Zukitwo"

- all subpackages except "gnome-shell-theme-*" share two subdirectories: "/usr/share/themes/Zukitwo/Zukitwo" and "/usr/share/themes/Zukitwo/Zukitwo-Dark"

- only "gnome-shell-theme-*" owns "/usr/share/themes/Zukitwo/Zukitwo-Shell"

If the "*-common" subpackage owned "/usr/share/themes/Zukitwo" only, then ownership of the above-mentioned two subdirs would be repeated in all subpackages except "gnome-shell-theme-*".
Instead, if it owned also the two subdirs, it would be useless when installing only "gnome-shell-theme-*".

What do you suggest me to do? Thank you.

Comment 53 Mattia M. 2012-07-12 12:57:47 UTC
Is it viable to make the "*-common" subpackage create and own also "/usr/share/themes/Zukitwo/Zukitwo-Shell" (in addition to "/usr/share/themes/Zukitwo/Zukitwo", "/usr/share/themes/Zukitwo/Zukitwo-Dark" and documentation files)?
The only issue is that, if one opted not to install "gnome-shell-theme-*", the (empty) "Zukitwo-Shell" directory would exist anyway.
What do you think?

Comment 54 Mattia M. 2012-07-13 07:10:09 UTC
Another alternative could be to 

- move the content of "/usr/share/themes/Zukitwo/Zukitwo-Shell" (i.e. the "gnome-shell" directory) into "/usr/share/themes/Zukitwo",

- not to create the "Zukitwo-Shell" directory at all and

- to have "*-common" own "/usr/share/themes/Zukitwo", "/usr/share/themes/Zukitwo/Zukitwo", "/usr/share/themes/Zukitwo/Zukitwo-Dark".

The GNOME Shell theme should work anyway, shouldn't it?

Comment 55 Mattia M. 2012-07-13 12:59:22 UTC
(In reply to comment #54)
> Another alternative could be to 
> 
> - move the content of "/usr/share/themes/Zukitwo/Zukitwo-Shell" (i.e. the
> "gnome-shell" directory) into "/usr/share/themes/Zukitwo",
> 
> - not to create the "Zukitwo-Shell" directory at all and
> 
> - to have "*-common" own "/usr/share/themes/Zukitwo",
> "/usr/share/themes/Zukitwo/Zukitwo",
> "/usr/share/themes/Zukitwo/Zukitwo-Dark".
> 
> The GNOME Shell theme should work anyway, shouldn't it?

I didn't noticed that doing as I proposed in comment #54 would produce the side effect of creating the empty directories ".../Zukitwo/Zukitwo" and "...Zukitwo/Zukitwo-Dark" even if one installed only "gnome-shell-theme-*".

Comment 56 Mattia M. 2012-08-02 10:19:11 UTC
(In reply to comment #52)
> I've been told that, when multiple subpackages share common
> directories/files, it's better to define a "*-common" subpackage which owns
> them.
> 
> As for Zukitwo, the situation is a bit complicated:
> 
> - all subpackages share documentation files and a common main directory:
> "/usr/share/themes/Zukitwo"
> 
> - all subpackages except "gnome-shell-theme-*" share two subdirectories:
> "/usr/share/themes/Zukitwo/Zukitwo" and
> "/usr/share/themes/Zukitwo/Zukitwo-Dark"
> 
> - only "gnome-shell-theme-*" owns "/usr/share/themes/Zukitwo/Zukitwo-Shell"
> 
> If the "*-common" subpackage owned "/usr/share/themes/Zukitwo" only, then
> ownership of the above-mentioned two subdirs would be repeated in all
> subpackages except "gnome-shell-theme-*".
> Instead, if it owned also the two subdirs, it would be useless when
> installing only "gnome-shell-theme-*".
> 
> What do you suggest me to do? Thank you.

Any suggestion about the above issue, please?
I'd like my package to be as much compliant to the quality standard of Fedora as possible, but for this I need your help.

Comment 57 Tim Lauridsen 2012-08-02 16:14:52 UTC
the gnome shell theme packages should be installed in and only own that dir

/usr/share/themes/Zukitwo/gnome-shell
/usr/share/themes/Zukitwo-Dark/gnome-shell

gtk-2 theme should be installed in and only own that dir.

/usr/share/themes/Zukitwo/gtk-2
/usr/share/themes/Zukitwo/gtk-3
etc.

The licens package should go into every package

if there is some other generel docs you can put it into at -common package and let the other packages require the -common package

Comment 58 Mattia M. 2012-08-03 04:25:11 UTC
Thank you.

(In reply to comment #57)

> The licens package should go into every package
> 
> if there is some other generel docs you can put it into at -common package
> and let the other packages require the -common package

I think you mean "license file".
As for the other packages I am maintaining, I put also the license file (i.e. COPYING) into the "*-common" subpackage only, since I thought that common should contain every shared file with no exceptions (please, see, e.g., http://pkgs.fedoraproject.org/cgit/zukiwi.git/tree/zukiwi.spec ).
So, in your opinion, I should also correct the other packages to make the license file be included in every single package (excluding "*.common" only)?

Comment 59 Tim Lauridsen 2012-08-03 12:02:02 UTC
As far as I remember it is ok to put the license file in a common as long as every other package requires the -common package.
So that the license file is install no matter what sub package you are installing

Comment 60 Mattia M. 2012-08-04 08:08:13 UTC
I modified the Spec file according to your suggestions.
Here it is: http://pkgs.fedoraproject.org/cgit/zukitwo.git/plain/zukitwo.spec?h=f17&id=e184ac37baf151b2804cb108cdc5bd78d657dc55

Please note that now the "gnome-shell" directory and its content are present in both "/usr/share/themes/Zukitwo/" and "/usr/share/themes/Zukitwo-Dark" (before a sole copy of them existed in "/usr/share/themes/Zukitwo-Shell/").

Comment 61 Tim Lauridsen 2012-08-05 06:21:11 UTC
Look fine to me.
A more cosmetic issue is having multiple requirement i a single line, it makes it hard to read, I would prefer that you add one require line for each requirement.

Ex.

Requires:       %{name}-common = %{version}-%{release}, gtk-murrine-engine >= 0.98.1.1 gtk2-engines

should be.

Requires:       %{name}-common = %{version}-%{release}
Requires:       gtk-murrine-engine >= 0.98.1.1
Requires:       gtk2-engines

It also make git diff easier to read when doing updates to requirement

Comment 62 Mattia M. 2012-08-05 07:10:54 UTC
By the way, just to avoid wasting disk space, I've replaced the copy of the "gnome-shell" directory inside "Zukitwo-Dark" with a symlink to that placed inside "Zukitwo". Rpmlint doesn't complain and the package installs and works fine.

(In reply to comment #61)
> A more cosmetic issue is having multiple requirement i a single line, it
> makes it hard to read, I would prefer that you add one require line for each
> requirement.
> 
> Ex.
> 
> Requires:       %{name}-common = %{version}-%{release}, gtk-murrine-engine
> >= 0.98.1.1 gtk2-engines
> 
> should be.
> 
> Requires:       %{name}-common = %{version}-%{release}
> Requires:       gtk-murrine-engine >= 0.98.1.1
> Requires:       gtk2-engines
> 
> It also make git diff easier to read when doing updates to requirement

I've already submitted the package to Koji; I'm going to do that cosmetic changed in the next release.
Thanks for your help!

Comment 63 Mattia M. 2012-08-05 07:16:02 UTC
(In reply to comment #62)
> I'm going to do that cosmetic >>>changed<<< in the next release.

Typo: "I'm going to do that cosmetic >>>changes<<< in the next release."


Note You need to log in before you can comment on or make changes to this bug.