Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)
On 12/12/2016 06:13 PM, proyvind wrote: Skimming through your link to suse's patterns, it's hard to easily grasp it's purpose, while if serving the same purpose, the implementation of is not only extremely confusing, hard to maintain and extremely non-standard fashion, rather than implemented in rpm itself in a proper, intuitively named way for wider adoption. As the group tag more recently has been made optional, with it's replacement that's not limiting to single tag value, requiring standardized set of groups being moved out of rpm, this is really bad considering cross-compatibility, with functionality tied to distro specific dependency solver. The groups tag was never standardized nor correctness enforced, so it is/was truly useless for almost all purposes. Probably seemed like a neat thing back in the nineties with a couple of hundred packages in the entire distro :) By rather introducing the trivially implementation of MetaTags:, a proper replacement for group tag is provided in rpm itself where it should be, while the support of multiple meta tags rather than group, aids the vendor specific groups that's not standardized across distros, leaving yet another obstacle for cross-distro packaging compatibility. I hope this better explains it's purpose, rationale, motivation and benefits of. :) I implemented essentially the same thing back in 2008 but with "keywords" as the tag. Never committed it since a free-form string array is likely to end up as a junkyard of typoed cruft - just like group was, only worse. Sort of related to that: for every reason to include such data in packages themselves, there's a counter-argument. For example, you really, really dont want to end up rebuilding the kernel or LibreOffice or such just to add, remove or typo-fix a keyword/tag. And tags in packages it's unlikely to be useful for, say, distro/spin-composing in the way eg comps is used. It's just one of those things that seems like a decent idea but coming up with an actual use-case isn't that easy. - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)
@proyvind @proyvind, I still didn't got use-case for this. Can you show some example? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/107#issuecomment-266473326___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Metatags (#107)
Skimming through your link to suse's patterns, it's hard to easily grasp it's purpose, while if serving the same purpose, the implementation of is not only extremely confusing, hard to maintain and extremely non-standard fashion, rather than implemented in rpm itself in a proper, intuitively named way for wider adoption. As the group tag more recently has been made optional, with it's replacement that's not limiting to single tag value, requiring standardized set of groups being moved out of rpm, this is really bad considering cross-compatibility, with functionality tied to distro specific dependency solver. By rather introducing the trivially implementation of MetaTags:, a proper replacement for group tag is provided in rpm itself where it should be, while the support of multiple meta tags rather than group, aids the vendor specific groups that's not standardized across distros, leaving yet another obstacle for cross-distro packaging compatibility. I hope this better explains it's purpose, rationale, motivation and benefits of. :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/107#issuecomment-266472856___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] When using %autopatch, create backup files with .~ suffix by def… (#109)
Taking a closer look at the mageia bug, I notice that the backup files lacks the '~' backup suffix, for which I'd consider this rather a mageia specific shortcoming in their %apply_patches implementation, cooker's not affected by.. The only scare thing about mageia's past use of %apply_patches I see, is faiure of producing proper/standardized backup files. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/109#issuecomment-266467946___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] When using %autopatch, create backup files with .~ suffix by def… (#109)
backup files included in packages are nothing but a result of faulty packaging, where disablingdefault non-intrusive functionality of use are clearly not the right solution and really should be considered flawed packaging practices and workarounds rather than correctly addressing and fixing the issue, a matter applied to software development in general. Prevention of this should already be ensured through rpmlint checks, where graded as error by default IIRC. Further on, the truly proper, automatic and guaranteed prevention of this to even be possible is through brp-* scripts run at end of %install. For cooker we have an almost two decades old spec-helper package with additional scripts to ensure packaging sanity, which I've over the past years have implemented even further extensive scripts, while cleaning them up (ie. such as spaghetti perl scripts difficult to maintain and read have been rewritten in shell scripts easy to understand and maintain), which now really is in a shape where not having pushed upstream earlier is almost an outrage.. :p I will create a branch with these commited to soon and create a pull request for. FWIW: We've *never* actually experienced this as an actual problem in cooker.. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/109#issuecomment-266466153___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
