24.01.2014 at 16:58 Stéphane Desneux
<[email protected]> wrote:
Maciej,
Please find some answers below.
On 24/01/2014 12:54, Maciej Wereski wrote:
First, every repository that uses some Tizen specific paths will have to
pull libtizenplatform-config-devel in requirements. Currently custom
Tizen
Yes.
macros can be found in packaging/rpm-tizen_macros. Maybe this would be
better location for these macros?
IMO, no.
By 'packaging/rpm-tizen_macros', you probably mean
platform/upstream/rpm/packaging/rpm-tizen_macros ? This is probably not
a good location, for a few reasons:
Yes, I'm talking about platform/upstream/rpm. Sorry' I've forgot to
mention that.
- the whole distro build depends on rpm: modifying rpm implies
rebuilding every package. Not sure that OBS admins would agree :-)
That's not an argument. We shouldn't be afraid of making changes, because
a lot of packages will have to be rebuilt.
- the macros (the names and values) are deduced from the file
tizen-platform.meta when building tizen-platform-config. It's safer to
keep things in the same package and have the rpm macros always synced
with the libtzplatform-config definitions (enum in C header). No build
headaches.
I think that we should have something like Tizen Filesystem Hierarchy
Standard, where all Tizen-specific paths are well defined. Other packages
(filesystem, rpm, rpmlint, libtizenplatform-config, ...) should just
implement it.
Also dispersing system-wide macros across multiple repositories will give
a headache developer, who'll like/have to read definitions of such macros.
I've stumbled upon tizen-platform-config by chance, so now I know where to
look, when I see TZ_XXX macro, but otherwise I'd started too look for it
in rpm-tizen_macros (especially that these macros will be used in many
packages).
- after all, it's usual for a package to distribute its macros in the
-devel package. Examples: glib2, pango, gtk, ...
devel packages provide rather package-specific macros then system-wide
paths. What's more we have some package-specific, but widely used paths
defined in platform/upstream/rpm and not in origin package (e.g. %_unitdir
defining systemd system unit directory). Also, packages, which require
devel package, don't do it only for macros (but also to link with
library). I've seen commits, where packages pull
libtizenplatform-config-devel only to use some RPM macro in one or two
places. IMO, that's an overkill.
Also current directory macros use other convention: "_${NAME}dir" all
lowercase, e.g. %{_unittdir}, %{_mandir}. Could these macros be renamed
to
fit this convention?
We chose to keep the same name everywhere:
- C/C++ enums
- bash variables
- env variables
- rpm macros
to avoid any confusion.
Another advantage: when we'll have bugs to fix regarding some paths or
platform vars, it will be easy to grep TZ_XXXX in the source tree.
Actually, grepping '/opt','app' or '5000' is really a hassle.
Every solution has its advantages and drawbacks. I'd just like to have
chosen solution well settled and documented on wiki (also it would be nice
to announce it on [Dev] after figuring everything out).
I hope this clarified things.
Kind regards,
Stéphane
Thanks.
regards,
--
Maciej Wereski
Samsung R&D Institute Poland
Samsung Electronics
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
