Changing project structure, packaging, naming

[actionless]

Regarding name (#116) so far I am thinking of themix so it will be used in the examples below.

Packages:
themix-full (metapackage, depends on rest of the packages, replaces oomox package)
themix-gui
themix-theme-oomox
themix-theme-materia
themix-icons-gnome-colors
themix-icons-archdroid
themix-export-spotify
themix-import-base16
themix-import-image

Executable names:

themix
themix-cli-oomox
themix-cli-materia
and so on or mb more explicit like themix-cli-theme-materia
And for compatibility:
oomox-gui -> themix
oomox-cli -> themix-cli-oomox
and so on

I was thinking about having single themix-cli entrypoint and things like themix-cli --theme oomox and themix-cli --theme materia but anyway we need to have single cli executables for each theme plugin, to make them able to work independently without main gui app installed.
-- extracted into #202

Also I am considering moving project to a dedicated github project to encourage more community participation since it won't look that much like a personal project.

To be done:

• finalize the decision on name 😃

• move repos to the new organization

• ./packaging/install_plugin.sh makefile targets for installing plugins

• writing new PKGBUILDs

• updating deb packaging and Dockerfile of deb-builder

• renaming Oomox->Themix in low-hanging-fruit cases (more complicated cases would go into separate tickets)

[alexarnaud]

I always plan to package Oomox into Debian repository. After lot of change of structure I have decided to wait a little bit to finalize this work. Do you think this change could be the last big one for the next year? I also agree with you, it could be great to have a community repository. Best regards and thanks for your great job, Alex. Le 14/03/2018 à 03:45, Yauhen Kirylau a écrit :

…

Regarding name (#116 <#116>) so far I am thinking of |themix| so it will be used in the examples below. Packages: |themix-full| (metapackage, depends on rest of the packages, replaces |oomox| package) |themix-gui| |themix-theme-oomox| |themix-theme-materia| |themix-icons-gnome-colors| |themix-icons-archdroid| |themix-export-spotify| |themix-format-base16| Executable names: |themix| |themix-cli| — not implemented yet And for compatibility: |oomox-gui| -> |themix| |oomox-cli| -> |themix-cli-oomox| and so on I was thinking about having single |themix-cli| entrypoint and things like |themix-cli --theme oomox| and |themix-cli --theme materia| but anyway we need to have single cli executables for each theme plugin, to make them able to work independently without main gui app installed. Also I am considering moving project to a dedicated github project to encourage more community participation since it won't look that much like a personal project. To be done: * |./packaging/install_plugin.sh| * writing new PKGBUILDs — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#129>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD_1DJ6MByOdnSayJvIIR3_A3_L4KShvks5teIRJgaJpZM4SpwQk>.

[actionless]

repository structure won't be affected, only packaging scripts, so if you are writing your own packaging scripts this change shouldn't affect you in any way except for the name change

(bin files are generated by packaging; and backward compatible symlinks will be also provided)

[alexarnaud]

Le 15/03/2018 à 01:54, Yauhen Kirylau a écrit :

repository structure won't be affected, only packaging scripts, so if you are writing your own packaging scripts this change shouldn't affect you in any way except for the name change

Right, but if you change the source name, Ill have to change the source package name and all package name and provide transitional package. It's not a big issue for downstream repository but I would prefer to have a proper package directly if push it to the official Debian repository to avoid transitional package. I mean transitional package the name package oomox will depends on the new name, oomox-cli will also depend on the new name etc. We couldn't drop package from the repository if people have installed with the previous name. We'll also change path and so provide symbolic links to keep things working for script. So IMO it's easier to push directly the right package with the right package name. Best regards, Alex.

[actionless]

yup, in that case it could be reasonable to wait for the name change

[actionless]

@AladW sorry for spamming you from here but mb you have some recommendation regarding packaging layout for Arch? ie the way how app will be splitted into the packages and if it should have a common group for them (see first message for the description)

[AladW]

Having 10 PKGBUILDs on AUR with different sources is probably annoying unless you go with unsupported means of installation (i.e. AUR helpers).

I'm not familiar with the build system you use here so don't know what should be split and where; but for a single PKGBUILD, I'd consider a git submodule approach both for git and release version. (cf. https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/pacutils)

[actionless]

so you think it's fine to leave it as is?
https://github.com/actionless/oomox/blob/master/packaging/arch/PKGBUILD#L14-L22

[actionless]

At the same time splitted packaging will help to remove dependency on Inkscape (which is needed only for Materia theme plugin).

[actionless]

@smurphos going to tag 1.6.1 quite soon (before end of the month)
before next planned release (1.7.0) i gonna move all the repos to the new organization

name will be changed for 1.8.0 or 2.0 (whichever of them will be next version after)