Spec URL: http://mwiriadi.fedorapeople.org/packages/ETL/ETL.spec SRPM URL: http://mwiriadi.fedorapeople.org/packages/ETL/ETL-devel-0.04.10-1.fc8.src.rpm Description: ETL is a multi-platform class and template library designed to add new datatypes and functions which combine well with the existing types and functions from the C++ Standard Template Library (STL).
starting review
* You need to download the sources with wget -N in order to prevent timestamps changes -rw-rw-r-- 1 builder builder 335182 jan 11 16:37 ETL-0.04.10.tar.gz instead of -rw-rw-r-- 1 builder builder 335182 oct 10 04:37 ETL-0.04.10.tar.gz * if the package name is ETL-devel, the spec file have to be ETL-devel.spec * License is GPLv2+ - good * The package do not seems to be arch independent but only because it has ETL.pc in /usr/lib64 on lib64 system - seems strange * you need to use: make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p" -rw-r--r-- 1 builder builder 1249 jan 15 12:39 value instead of -rw-r--r-- 1 builder builder 1249 mar 16 2007 value * etl_profile.h is a config.h kind of file. usually it shouldn't be installed. same as etl_config.h - If upstream claims they are really needed, then it might be interesting to keep a timestamps reference from a file to avoid multiarches conflict (but only if they are the same on i386 and x86_64, and also ppc and ppc64 at least). Might be safe to remove ETL-config then. (and to patch dependant apps to use pkg-config if needed). see http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks * The package bundle no library - as such it is not needed to have /sbin/ldconfig in post and postun. * pkg-config file: ETL.pc - it Requires only But includedir remains includedir=/usr/include instead of includedir=/usr/include/ETL as such they is a need to check if headers of dependent packages have ETL/spline or only spline (for example). Might need to test package that links against it... specially if others libs are missing. * As the package isn't marked as noarch (might evaluate if it could be with a tweak for pkg-config) a debuginfo is generated. If the package remains arch dependant, we might consider to use %define debug_package %{nil}. If the package could be noarch, then it might need to work on x86 x86_64 ppc ppc64 (and maybe others arch). then no debuginfo package will be created.
should be read: * pkg-config file: ETL.pc - it Requires only -lpthread koji scratch build request at: http://koji.fedoraproject.org/koji/taskinfo?taskID=350044 Looking at the headers looks differents or same for each arches...
Blocker: /usr/bin/ETL-config is not multilib ready. I recommend to re-write it as a wrapper around pkg-config.
Thx for your advice Ralf: Actually the only difference between ppc and x86_64 (for example and expect for the pkgconfig path for libdir is: ---------------- diff -uNr usr/include/ETL/etl_profile.h usr-x86_64/include/ETL/etl_profile.h --- usr/include/ETL/etl_profile.h 2008-01-15 13:49:01.000000000 +0100 +++ usr-x86_64/include/ETL/etl_profile.h 2008-01-15 13:49:01.000000000 +0100 @@ -129,7 +129,7 @@ /* Define to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ -#define WORDS_BIGENDIAN 1 +/* #undef WORDS_BIGENDIAN */ /* define if the vsnprintf function is mangled */ /* #undef vsnprintf */ ---------- But this define isn't used elsewhere than in etl_profile.h. If we can consider this as a noach package, then we might need to rip out these lines... Instead of using ETL-config, i was think about having this: (see attachement)
Created attachment 291713 [details] workaround for the pkgconfig on lib64 system
I have sent an email upstream to get some further information. I think it is prudent to talk to upstream to see where they view the current situation and what the best method is to go about sorting it out. If nothing comes of it I'll start working on patching what I can and trying to fix things. Thanks Nic for the updated Spec file that will come in handy. What I might do to get further information is to actually scan the source files of synfig to see what else is needed from in here as per one of your points then go from there.
(In reply to comment #5) > Thx for your advice Ralf: The killer is this: -- i386/bin/ETL-config 2008-01-15 13:39:03.000000000 +0100 +++ x86_64/bin/ETL-config 2008-01-15 13:38:56.000000000 +0100 @@ -9,7 +9,7 @@ sysconfdir=/etc sharedstatedir=/usr/com localstatedir=/var -libdir=/usr/lib +libdir=/usr/lib64 infodir=/usr/share/info mandir=/usr/share/man includedir=/usr/include This is a blocker, because it prevent you from installing 386 and the x86_64 packages in parallel. > Actually the only difference between ppc and x86_64 (for example and expect for the pkgconfig path for libdir is: > ---------------- > diff -uNr usr/include/ETL/etl_profile.h usr-x86_64/include/ETL/etl_profile.h > --- usr/include/ETL/etl_profile.h 2008-01-15 13:49:01.000000000 +0100 > +++ usr-x86_64/include/ETL/etl_profile.h 2008-01-15 13:49:01.000000000 +0100 > @@ -129,7 +129,7 @@ > > /* Define to 1 if your processor stores words with the most significant byte > first (like Motorola and SPARC, unlike Intel and VAX). */ > -#define WORDS_BIGENDIAN 1 > +/* #undef WORDS_BIGENDIAN */ Bummer. This is yet another blocker. They are exporting a define which clashes with autoconf's autoheaders. This will render this package unusable with any autoconf based package using AC_BIG_ENDIAN (cf. info autoconf) and gcc43. Worse. Your remark had caused me to have a closer look into the headers. They are scattered with autoheader defines which all will trigger the same issue as outlined above. IMO, this package is not in a shape to be added. I recommend to withdraw it.
Well Ralf raise a real problem... And i would give a chance to have an answear from upstream...But indeed, I won't approve anything that isn't gcc43 compliant. There is also the question to add some headers without any libs... I wonder if this make sense, specially if only one package use it. Does theses headers could be merged with another package ?
(In reply to comment #9) > And i would give a chance to have an answear > from upstream... Yes, this is an issue that should be fixed upstream. > There is also the question to add some headers without any libs... > I wonder if this make sense, specially if only one package use it. Does theses > headers could be merged with another package ? I don't understand this remark. Could you elaborate?
Hi, I'm one of the people helping with development upstream. We inherited the synfig source code - it was GPLed after being proprietary: http://synfig.org/History We'd appreciate it if you could come to #synfig on irc.freenode.net, explain the issues that need fixing and help us to fix them. Look for either dooglus or pabs3. Alternatively please file bugs/patches in the tracker linked here: http://synfig.org/Bugs Once ETL/synfig/synfigstudio are in Fedora, please edit these pages: http://synfig.org/Download http://synfig.org/Bugs
Forgot to ask you to edit this to indicate the Fedora package names of the build-dependencies: http://synfig.org/Build_instructions
I don't know if you got my email before. There are few issues with etl as you can see from this thread. The bugs listed are in the thread itself if you would like to comment. At the moment the package is on hold and will not make it into Fedora without the fixes to the code listed above.
I was able to build synfig with Debian's g++ 4.3 fine, but not synfigstudio due to this bug in sigc++: http://bugs.debian.org/456971 When that is resolved, I'll try it again. If Fedora has a fix for it, please try building synfigstudio with it.
Have you checked your defines to make sure they don't clash with other packages. The example given was in your etl_profile_.h.in ETL-config This is a blocker, because it prevent you from installing 386 and the x86_64 packages in parallel. quoting from ralf btw: Your remark had caused me to have a closer look into the headers. They are scattered with autoheader defines which all will trigger the same issue as outlined above. In reference to the clash's if you change your defines they should be fine. The etl-config issue as well. One other question why does it need a static library since we remove it after building?
Defines: not yet, help welcome. ETL-config is generated from ETL-config.in at configure time. Removing it upstream would be OK, since synfig/studio don't use it as far as I can see. Not sure which static library you mean, ETL is just a bunch of C++ templates.
(In reply to comment #16) > Defines: not yet, help welcome. Provided how this package is designed, fixing this is close to impossible. One way to work around this would be to rename all defines and to use a second, private, manually written autoheader, which would be installed into $(libdir) instead of $(includedir). Packages using ETL then would be required to use -I$(libdir)/ETL to pickup this header (c.f. how glib2 and gtk2 install their headers) > ETL-config is generated from ETL-config.in at configure time. This is pretty easy to fix. The key is not to store any configuration info in files which are not in multilib'ed dirs. I.e. not to store @libdir@ in $(bindir)/ETL-config, but to let $(bindir)/ETL-config pick up this info from a different location. A common trick is to implement $(bindir)/*-config as wrappers around pkgconfig. (*.pc's are being stored into $(libdir)/pkgconfig (libdir is multilib'ed. e.g. */lib on ix32 and */lib64 on ix64) > Removing it > upstream would be OK, since synfig/studio don't use it as far as I can see. Exactly this is the cause of your problems with the #defines. If they were, you could move these headers into $(libdir) and let ETL.pc use Cflags= -I$(libdir)/ETL or similar.
Created attachment 292726 [details] Rewrite ETL-config as wrapper to pkgconfig This patch implements $(bindir)/ETL-config as a wrapper around pkg-config. c.f. my previous comment. It avoids hardcoding config values into files inside of non-multilib'ed dirs.
Patch committed to synfig svn.
http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel.spec http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel-0.04.10-2.fc8.src.rpm
From the package point of view: This seems fine. I would just remove ETL-config as this will lead to mutliarch conflict (as Ralf state). As synfig do not use it, this shouldn't matter) From the code point of view: When trying to build synfig I've had: /usr/include/ETL/_surface.h:196: error: 'memcpy' was not declared in this scope So you need to add the missing include (cstring in this case). One note about synfig, there are a lot of missing BR (see the Configuration Summary) - That would be fine to add them when they are available within Fedora. There is also a libavcodec optionnal requirement, and maybe it would be good to provide it as a plugin form third part repository...
ETL-config has been rewritten as a pkg-config wrapper (see patch above). _surface.h error has a one-line fix (#include <cstring>) and was fixed in SVN ages ago thanks to Debian.
OK! so about gcc4.3.0 the packager also need to backport the patch. (as we now have pre gcc 4.3.0 in rawhide). About the ETL-config, since this file is generated at a configure step, packager will need to set the same timestamps from a reference file for all arches . This can be done using touch -r any_reference_file $RPM_BUILD_ROOT%{_bindir}/ETL-config
Upstream is planning on releasing a new version at the end of this month early next month to be compliant with gcc43. As F-9 will contain gcc43 I will wait till the new release and repackage for that. The wrapper is included in upstream already so I will be closer to upstream.
As you like, but this patch is often trivial, and that would be a good thing to have backported and tested so we could start review synfig.
Actually you make a fair point since there are still 2 other packages linked to this one. http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel-0.04.10-3.fc8.src.rpm http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel.spec Updated with the patch.
oups! I was close to ping you but actually you should have ping me ! so i'm testing 0.04.10-3 but 0.01.11 is here...
synfig failed with on Rawhide with gcc43 blur.cpp:134: error: explicit template specialization cannot have a storage class As synfig is a known package using ETL-devel I cannot approve ETL-devel until synfig is fixed. starting prelimary review of synfig
That is correct. It is fixed in cvs currently in upstream. They are planning a release shortly. Hence I haven't done anything yet. I was hoping this would work so it would be a simple upgrade/update.
My bad, upstream has released a new version. I've re-packaged it. http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel-0.4.11-1.fc9.src.rpm http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-devel.spec
Two show stoppers: 1. The header files are still as dirty as they used to be. This package's headers are polluted with HAVE_* defines. 2. Why is this package called ETL-devel? The package's name is ETL => ETL.spec, ETL-<version>-<release>.src.rpm There is nothing wrong in letting this ETL.src.rpm only build an ETL-devel.rpm.
I originally had the spec file as ETL.spec but changed it to ETL-devel as part of the review. Ralf if I removed the HAVE_* would that work since the requirements for the packages are there anyway the HAVE seem to be doing the packagers job. The configure finds it anyways.
Ralf it seems like the only file is etl_profile.h [marc@localhost ETL-0.4.11]$ grep -r '#define HAVE_ *' ./* ./configure:#define HAVE_LIBUSER32 1 ./configure:#define HAVE_LIBKERNEL32 1 ./configure:#define HAVE_LIBPTHREAD 1 ./configure:#define HAVE_VSNPRINTF 1 ./ETL/etl_profile.h:#define HAVE_FORK 1 ./ETL/etl_profile.h:#define HAVE_GETTIMEOFDAY 1 ./ETL/etl_profile.h:#define HAVE_INTTYPES_H 1 ./ETL/etl_profile.h:#define HAVE_KILL 1 ./ETL/etl_profile.h:#define HAVE_LIBPTHREAD 1 ./ETL/etl_profile.h:#define HAVE_MEMORY_H 1 ./ETL/etl_profile.h:#define HAVE_PIPE 1 ./ETL/etl_profile.h:#define HAVE_PTHREAD_CREATE 1 ./ETL/etl_profile.h:#define HAVE_PTHREAD_H 1 ./ETL/etl_profile.h:#define HAVE_PTHREAD_RWLOCK_INIT 1 ./ETL/etl_profile.h:#define HAVE_PTHREAD_YIELD 1 ./ETL/etl_profile.h:#define HAVE_SCHED_H 1 ./ETL/etl_profile.h:#define HAVE_SCHED_YIELD 1 ./ETL/etl_profile.h:#define HAVE_SSCANF 1 ./ETL/etl_profile.h:#define HAVE_STDINT_H 1 ./ETL/etl_profile.h:#define HAVE_STDLIB_H 1 ./ETL/etl_profile.h:#define HAVE_STRINGS_H 1 ./ETL/etl_profile.h:#define HAVE_STRING_H 1 ./ETL/etl_profile.h:#define HAVE_SYS_STAT_H 1 ./ETL/etl_profile.h:#define HAVE_SYS_TIMES_H 1 ./ETL/etl_profile.h:#define HAVE_SYS_TIME_H 1 ./ETL/etl_profile.h:#define HAVE_SYS_TYPES_H 1 ./ETL/etl_profile.h:#define HAVE_UNISTD_H 1 ./ETL/etl_profile.h:#define HAVE_VASPRINTF 1 ./ETL/etl_profile.h:#define HAVE_VSNPRINTF 1 ./ETL/etl_profile.h:#define HAVE_VSPRINTF 1 ./ETL/etl_profile.h:#define HAVE_VSSCANF 1 ./ETL/etl_profile.h:#define HAVE___CLONE 1 ./ETL.pbproj/etl_profile.h:#define HAVE_GETTIMEOFDAY ./ETL.pbproj/etl_profile.h:#define HAVE_PTHREAD_H ./ETL.pbproj/etl_profile.h:#define HAVE_SCHED_H ./ETL.pbproj/etl_profile.h:#define HAVE_PTHREAD_CREATE ./ETL.pbproj/etl_profile.h:#define HAVE_VASPRINTF ./ETL.pbproj/etl_profile.h:#define HAVE_VSNPRINTF ./ETL.pbproj/etl_profile.h:#define HAVE_VSPRINTF
Created attachment 297176 [details] profile cleanup Ralf would this work provided the other etl_profile.h are removed.
bleh ignore this it needs more testing doesn't compile with synfig
I think it works...........Ralf can you verify that this no longer has a blocker. http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL.spec http://mwiriadi.fedorapeople.org/packages/ETL-devel/ETL-0.4.11-2.fc9.src.rpm
Ping
/var/tmp/rpm-tmp.41093: line 40: autoreconf: command not found Missing BR: automake But the etl_profile.h is still here! In my mind it should be removed and the tests for definitions should be done by synfig. This would remove the need of using autotools for ETL and thus, produce a clean noarch package for ETL (without pkgconfig nor ETL-config needs as it just need to find where are the headers, use -lpthread and the proper HAVE_ definitions for ETL). On the other side: this is a special case here as no lib is built. So, removing any config.h-like file is like removing it after the configure step and before building the software on the usual case. In this case, this is senseless and in my mind we may keep this etl_profile.h ... Others point of view can be expressed... for now, T'm test building synfig for F-9 with this package...
For me provided I can build synfig and synfig-studio is all I'm concerned about. Synfig-studio is not up for review as of yet because I want etl and synfig ready before I bring that for review.
I forgot to say that it has failed to build on F-9 x86_64 undefined reference to g_uri_get_scheme collect2: ld returned 1 exit status I don't knwo where this symbol is present, i don't seems to have it available on my system.
ETL/synfig/synfigstudio don't use that function. From google it looks like it was part of glib at one point but was renamed.
Is this really an issue the following code. /* Define to the address where bug reports for this package should be sent. */ #define ETL_BUGREPORT "http://synfig.org/Bugs" /* Define to the full name of this package. */ #define ETL_NAME "Extended Template Library" /* Define to the full name and version of this package. */ #define ETL_STRING "Extended Template Library 0.4.11" /* Define to the one symbol short name of this package. */ #define ETL_TARNAME "ETL" /* Define to the version of this package. */ #define ETL_VERSION "0.4.11"
(In reply to comment #41) > ETL/synfig/synfigstudio don't use that function. From google it looks like it > was part of glib at one point but was renamed. Maybe there is a missing -lstdc++ somewhere ?
http://koji.fedoraproject.org/koji/taskinfo?taskID=564701 I don't see any issue? Sorry my computer died and I'm now using my laptop instead of my other box. Well PSU died and I haven't fixed it as of yet.
The problem isn't with ETL but with synfig using ETL. I cannot approve ETL if the dependent package that is supposed to be useful fails. (at least on Rawhide x86_64) I will give a retry...
Can you paste the build errors or a link to them?
Ok this time the build went fine on x86_64. (either synfig or others dependencies have been fixed probably) So we are close. About ETL, it still miss BuildRequires libtool and /usr/bin/ETL-config /usr/include/ETL/etl_profile.h need to have a timestamps reference like: touch -r ChangeLog $RPM_BUILD_ROOT%{_bindir}/ETL-config touch -r ChangeLog $RPM_BUILD_ROOT%{_includedir}/ETL/etl_profile.h As they are already the same files but have different timestamps
http://mwiriadi.fedorapeople.org/packages/ETL/ETL-0.4.11-3.fc9.src.rpm http://mwiriadi.fedorapeople.org/packages/ETL/ETL.spec Hopefully done http://koji.fedoraproject.org/koji/taskinfo?taskID=591446
>Buildrequires: automake, libtool >Requires: pkgconfig, automake Buildrequires: libtool will be enought as it will bring autoconf automake But Adding Requires automake isn't needed by ETL itself. Fix that and i will approve the package. (it finally built with synfig and F-9 x86_64) might be a bug with a dependency or fixed in newer version...
http://mwiriadi.fedorapeople.org/packages/ETL/ETL.spec http://mwiriadi.fedorapeople.org/packages/ETL/ETL-0.4.11-4.fc9.src.rpm Removed automake and automake Buildrequires: libtool Requires: pkgconfig Cheers Nicolas for your help.
Ok - Why do you have no space between this: Requires: pkgconfig %description That's important to have a spec file readable, as everyone can take a look on it and watch commit logs. (same for one line BuildRequires). Anyway... ---------------- This package (ETL) is approved by me ----------------
(In reply to comment #51) > This package (ETL) is approved by me Urgh, why did you do this? IMNSHO, this package is of a too poor quality to let in into Fedora. In particular, none of its silly HAVE_ define issues have been fixed.
> IMNSHO, this package is of a too poor quality to let in into Fedora. Do you see other problem than the etl_profile.h to say it's poor ? > In particular, none of its silly HAVE_ define issues have been fixed. > Well as ETL and synfig build fine i would only see this a an improvement. Many packages still use a config.h like package (for example mozilla-config.h from mozilla/firefox/xulrunner). But as you disagree I won't object. NEED_WORK: remove all config.h like files from the package. Thoses need to be checked by the dependant application at configure time.
(In reply to comment #53) > > IMNSHO, this package is of a too poor quality to let in into Fedora. > Do you see other problem than the etl_profile.h to say it's poor ? This bug alone a BLOCKER and a MUSTFIX. The problem behind this and the fact nobody has been able to come up with a quick-fix are caused by this package suffering from fundamental design flaws. > > In particular, none of its silly HAVE_ define issues have been fixed. > Well as ETL and synfig build fine i would only see this a an improvement. The point is: You are trying to ship ETL as standalone devel-package. The HAVE_ defines disqualifies it from such usages. > Many packages still use a config.h like package (for example mozilla-config.h > from mozilla/firefox/xulrunner). I haven't checked this particular case, but it's likely the a similar mis-design. There have been several of similar cases around, with some of them having been ironed out over time, and some of them not having been fixed.
@Marc Did you understood what you need to do ? upstream agreed to add the patch but i have no time for providing it. Would be better if you can work on it as you want to be the maintainer of this package.
Yeah I have been busy with $RL work so I'll start on it tonight hopefully.
ping ?
Again, ping ? don't forget to ask if you get lost with what to do...
Nicholas, you might want to check bug 429809.
Any progress with this package? I can take it, if necessary.
New version released, please update. If there are any patches you need, please send them our way.
New upstream release (stepping in since the original submitter seems unresponsive): SRPMS: http://v3.sk/~lkundrak/SRPMS/ETL-0.04.12-4.el5.src.rpm SPEC: http://v3.sk/~lkundrak/SPECS/ETL.spec * HAVE_* macros have been renamed to avoid clash with autoconf. "config.h-like" file etl_profile.h was not removed, since upstream does not do that, and I tend to think that it's the good way to go. See -- this would add a requirement for programs that use this to define ~10 macros prior to include the header, which can be non-trivial and ugly for programs that don't rely on autoconf && friends. And in case a new one gets added it could unnecessarily break compatibility, possibly resulting into builds with feature set smaller than intended. I don't think doing that with this added maintenance cost is a good idea. There is a prior art as well -- many packages hardcode feature set at build time. Rpmlint is silent, this builds in f11 mock and synfig with synfig studio build cleanly against this as well.
Sorry; I forgot to reset the revision, here are new packages: SRPMS: http://v3.sk/~lkundrak/SRPMS/ETL-0.04.12-1.el5.src.rpm SPEC: http://v3.sk/~lkundrak/SPECS/ETL.spec
ETL is an header-only package, why split in ETL and ETL-devel? I've been told that you can proceed either way but I think that having only ETL is better. By the way: are you a sponsored packager (I couldn't find you in the packager group). If not, you'll have to wait a sponsor to step in and review the package.
(In reply to comment #64) > ETL is an header-only package, why split in ETL and ETL-devel? I've been told > that you can proceed either way but I think that having only ETL is better. I don't split the package. The only binary (well, non-src) package that gets built from this package is ETL-devel, there's no main package, since because there's no %files section other than one for -devel subpackage. Package guidelines suggest that packages with content like this should be in -devel subpackage. https://fedoraproject.org/wiki/Packaging/Guidelines#Devel_Packages It could be argued that this package is exceptional, since it is only useful for development, but I find it much more consistent to call it -devel. It is only useful for development, not run-time and the -devel name makes is easily distinguishable as such not only to the user, but also to the tools (such as rpmdev-rmdevelrpms). This is also more future-proof (for the unlikely cause it gains some library code). It might be a good idea to provide ETL now though. > By the way: are you a sponsored packager (I couldn't find you in the packager > group). If not, you'll have to wait a sponsor to step in and review the > package. Yup, I am sponsored. I believe you can view my groups there, and packager is among those: https://admin.fedoraproject.org/accounts/user/view/lkundrak
Look at https://bugzilla.redhat.com/show_bug.cgi?id=428567#c17 The current package miss the etl_profile.h move into %{_libdir}/ETL and the related adds in ETL.pc (Cflags: -I${includedir} -I${libdir}/ETL) If ever the current ETL_HAS_ are the same with both arches on multilibs system, I would still prefer this solution since it will still be valid if others ETL_HAVE need to be introduced later. About the package name. One could say this is not a -devel but a -headers subpackage only, since it doesn't contain the symlink to a shared object. But -devel and -headers only exist when there is a "main" package also. (kernel-headers and kernel-devel exist because they are for a different usage than the kernel package itself.) Since there is no such "main" package, I think the current package is the main. In other words: From one side, I don't see anything to override the Fedora guideline which tell to use the upstream source archive name as the "source" package name. https://fedoraproject.org/wiki/Packaging/NamingGuidelines#General_Naming See also https://bugzilla.redhat.com/show_bug.cgi?id=428567#c31 On the other side, it remains possible for the ETL source package to only build an ETL-devel or ETL-headers package. (or to have only the ETL-%{version}-%{release}.src.rpm just build a plain ETL-%{version}-%{release}.%{_target_cpu}.rpm) (either using ETL-devel or ETL, the pkgconfig(ETL) provides will be properly extracted).
any question / tought ?
(In reply to comment #66) > Look at > https://bugzilla.redhat.com/show_bug.cgi?id=428567#c17 > The current package miss the etl_profile.h move into %{_libdir}/ETL and the > related adds in ETL.pc (Cflags: -I${includedir} -I${libdir}/ETL) > If ever the current ETL_HAS_ are the same with both arches on multilibs system, > I would still prefer this solution since it will still be valid if others > ETL_HAVE need to be introduced later. etl_profile.h can not be moved there, apart from it not being a good idea, FHS forbids that. In case the include files become arch-dependent (which is not likely anyways), the be renamed and a header that would include one depending on __WORD_SIZE will be in their original place. This is a common practice. > About the package name. One could say this is not a -devel but a -headers > subpackage only, since it doesn't contain the symlink to a shared object. > But -devel and -headers only exist when there is a "main" package also. > (kernel-headers and kernel-devel exist because they are for a different usage > than the kernel package itself.) > Since there is no such "main" package, I think the current package is the main. > > In other words: > From one side, I don't see anything to override the Fedora guideline which tell > to use the upstream source archive name as the "source" package name. > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#General_Naming > See also https://bugzilla.redhat.com/show_bug.cgi?id=428567#c31 > > On the other side, it remains possible for the ETL source package to only build > an ETL-devel or ETL-headers package. (or to have only the > ETL-%{version}-%{release}.src.rpm just build a plain > ETL-%{version}-%{release}.%{_target_cpu}.rpm) > > (either using ETL-devel or ETL, the pkgconfig(ETL) provides will be properly > extracted). When someone says "devel package", what comes to my mind is "useful for development", not "having a symlink to shared object" and I'd like to leave it that way. I think you see that this might be a matter of personal taste and doesn't violate guidelines, so I'm not going to change it unless there's a really serious objection.
(In reply to comment #68) > (In reply to comment #66) > likely anyways), the be renamed and a header that would include one depending > on __WORD_SIZE will be in their original place. This is a common practice. It would be an accurate solution, indeed. > When someone says "devel package", what comes to my mind is "useful for > development" Actually the package name is already ETL which only produce an ETL-devel. So I think we are good. I'm looking synfig/synfig studio to have usability tests of the ETL package...
package ETL is APPROVED
any news ?
New Package CVS Request ======================= Package Name: ETL Short Description: Extended Template Library Owners: lkundrak (anyone who wants to comaintiain this, feel free to opt in) Branches: EL-5 F-10
cvs done.
Imported and built. Thanks for good review and CVS.
Lubomir etc, could you please review this alternate patch: http://patches.synfig.org/r/25/diff/#index_header Please note that some of the Fedora changes are already committed in SVN and some related changes are also in SVN. The patch does the following: Generate etl_profile.h in a less hacky way. Move the tests needed for generating etl_profile.h into configure.ac. Use less generic defines in the etl_profile.h header Prefix private defines with a double underscore. Move the etl_profile.h header to an arch-specific dir to prepare for multi-arch.
(In reply to comment #75) > Lubomir etc, could you please review this alternate patch: > > http://patches.synfig.org/r/25/diff/#index_header Seems very well. Thanks!