https://bugzilla.redhat.com/show_bug.cgi?id=1359412 Andrew J. Schorr <aschorr@xxxxxxxxxxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ajschorr@alumni.p | |rinceton.edu) | --- Comment #7 from Andrew J. Schorr <aschorr@xxxxxxxxxxxxxxxxxxxxxxxxx> --- Hi! (In reply to David Kaspar [Dee'Kej] from comment #5) > Yeah, I'm aware that those are not same. :) I was just thinking to come up > with some naming schema to avoid some possible issues in the future. It's > really pain in the a** to be forced to create a pacake with new name just to > solve some problems. ;) Understood. I agree that it's important to get this right. > So, currently we have: > * gawk [the main package] > * gawk-devel [subpackage] > * gawk-doc [subpackage] > * gawk-debuginfo [automatically created subpackage] > > In case we will have the 'gawkextlib' package (to follow FPG rule to have > the name as close to upstream name as possible), then I wouls suggest this > naming schema: > * gawkextlib [the main package, which is necessary for your other extensions] > * gawkextlib-devel [subpackage necessary for developers] > * gawkextlib-doc [subpackage containing documentation, if any exists] > * gawkextlib-xml [the module/extension used with gawkextlib] > * gawkextlib-pgsql [the module/extension used with gawkextlib] > * gawkextlib-mpfr [the module/extension used with gawkextlib] > > This way it would be clearly visible by the name that the modules/extensions > are part of the the bigger "collection", and that they cannot function > without the main (base) package. I understand where you're coming from, but not all of the modules in the gawkextlib collection require the use of the gawkextlib support library. Some modules use it, and others do not. We would like these to be thought of as gawk extension modules, not gawkextlib extension modules. Conceptually, we're aiming for something like CPAN. Those are perl modules, not CPAN modules, as I understand it. > I was even thinking that you could create these modules/extensions as > subpackages of the gawkextlib, but I see that you versioning is not united > across these packages. The maintenance for this approach might be simpler, > but updating a module would require rebuild of whole thing. I definitely do not want to do that. Again, the conceptual model here is CPAN. We want each module to be maintained independently. IMHO, it would not be a good idea to package them together. > If you do not want to create this "collection" as subpackages, you can just > create each package separate as it is, which will look the same as above, > but will be versioned & build separately. You will have more specfiles to > maintain, but IMHO this might be the best course of action. :) I agree that they must be maintained separately, with a separate spec file for each one. The gawkextlib project attempts to provide a template that will make this easier. > In case your modules/extensions are able to function *without* the > 'gawkextlib', then I would follow this naming scheme: (As I mentioned above, some of the modules are able to function without gawkextlib, and some require it. That decision is made separately by each developer depending on whether he wants to use the support functions in the gawkextlib library.) > * gawkextlib [optional library for gawk] > * gawkextlib-devel [subpackage necessary for developers] > * gawkextlib-doc [subpackage containing documentation, if any exists] > * gawk-xml [independent extension to gawkextlib used for gawk itself] > * gawk-pgsql [independent extension to gawkextlib used for gawk itself] > * gawk-mpfr [independent extension to gawkextlib used for gawk itself] That is my preferred naming convention, and I think is consistent with the approach we have taken so far. > Ah, OK. In that case I would just slightly rewrite the current %description > to match the *Summary*, maybe like this? :) > > "%{name} is a library providing common support infrastructure for gawk > extensions. This particular package provides the 'libgawkextlib', which is > used by various gawk extension modules -- for example gawk-xml, gawk-pgsql, > and more." I updated the description to the following: %{name} is a library providing common support infrastructure for gawk extensions. This package provides 'libgawkextlib', which is used by various gawk extension modules -- for example gawk-xml, gawk-pgsql, and more. Is that OK? > I don't know what the h*ll I wrote there... :D Seriously, that sentence from > me does not make any sense. I'm not surprised you were confused... :D > Looking at the current specfile, it seems OK. ;) :-) > "The %{name}-devel package contains the header files and libraries > needed to develop gawk extension modules that use %{name} facilities." I made that change. > Yes, you are right. It is by default enabled in current Fedora releases. > However, there might come a point where we might like to get this package in > RHEL or EPEL. In that case AFAIK the package should be build with > preconfigured environment for RHEL/EPEL, which will most likely not have the > hardened build enabled by default. > > So I personally add the hardened build anywhere, just to be safe. :) Makes sense. It's in there. > I'm not a legal expert myself, but your clarification makes sense. :) And > changing licenses for FOSS projects can really be very painful, I wouldn't > advise that much. That's why it was just a question I was intrigued by. ;) Fair enough. Let's stick with GPL. > Thanks for the info, and all the changes you have made to the spec to > confirm to FPG rules. I really like it. :) Good. I'm glad we're getting close. :-) > The main (only?) question right now remains on how do you decide to proceed > with the naming of packages (see above). Please see my thoughts above. I think we have the correct naming convention. I will run it by Arnold to confirm that he agrees. Thanks, Andy -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
