| Summary: | dev-lang/lua:5.1 renames pkg-config file | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Julian Ospald <hasufell> |
| Component: | Current packages | Assignee: | Matti Bickel (RETIRED) <mabi> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | rafaelmartins, seemantk |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 445618 | ||
|
Description
Julian Ospald
2014-05-02 14:18:09 UTC
Upstream prefers static linking - this means slotting is a non-issue for them. You probably see what's the problem here - unless they can be convinced otherwise, this *needs* to suck in one way or another. (In reply to Rafał Mużyło from comment #1) > Upstream prefers static linking - this means slotting is a non-issue for > them. > > You probably see what's the problem here - unless they can be convinced > otherwise, this *needs* to suck in one way or another. Yeah, you are correct. They wont be convinced in any way, I'm sure. Actually, I think that at this point they just ignore any request regarding dynamically linkink lua. This is just a big waste of time. (In reply to Rafał Mużyło from comment #1) > Upstream prefers static linking - this means slotting is a non-issue for > them. > Seems to me they were just unable to implement it properly. There is no actual technical reason why they only provide make rules for static libs. > You probably see what's the problem here - unless they can be convinced > otherwise, this *needs* to suck in one way or another. There are different levels of hacks. One is to improve security, the other is to break stuff (like debian does). This approach breaks stuff. Removing the shared lib is a valid point, but will give us the usual security disadvantages. (In reply to Julian Ospald (hasufell) from comment #3) > (In reply to Rafał Mużyło from comment #1) > > Upstream prefers static linking - this means slotting is a non-issue for > > them. > > > > Seems to me they were just unable to implement it properly. There is no > actual technical reason why they only provide make rules for static libs. This isn't really true. I already chated with a few people that work at lablua about several aspects of it, and I'm quite sure that they are capable of implement libtool support easily, and were already overloaded with community patches implementing this. The true is that they don't want lua linked dynamically due to its nature and for easily of maintenance. And knowing that people a bit, I can say that upstream lua dynamically linked is something that isn't going to happen any time soon. > > You probably see what's the problem here - unless they can be convinced > > otherwise, this *needs* to suck in one way or another. > > There are different levels of hacks. One is to improve security, the other > is to break stuff (like debian does). This approach breaks stuff. > > Removing the shared lib is a valid point, but will give us the usual > security disadvantages. It's the only way to go, IMHO. They work hard to keep lua simple and easily auditable, so the security disadvantages should be minimized. Also, they have several big lua deployments. They care a lot about its stability and security. (In reply to Rafael Martins from comment #4) > (In reply to Julian Ospald (hasufell) from comment #3) > > (In reply to Rafał Mużyło from comment #1) > > > Upstream prefers static linking - this means slotting is a non-issue for > > > them. > > > > > > > Seems to me they were just unable to implement it properly. There is no > > actual technical reason why they only provide make rules for static libs. > > The true is that they don't want lua > linked dynamically due to its nature and for easily of maintenance. > I'm not sure I understand this argument. What do you mean by "nature" and why do they think a static-only lib is in any way easier to maintain? I skimmed through the ML and did not find any real explanation. > And knowing that people a bit, I can say that upstream lua dynamically > linked is something that isn't going to happen any time soon. > > > > You probably see what's the problem here - unless they can be convinced > > > otherwise, this *needs* to suck in one way or another. > > > > There are different levels of hacks. One is to improve security, the other > > is to break stuff (like debian does). This approach breaks stuff. > > > > Removing the shared lib is a valid point, but will give us the usual > > security disadvantages. > > It's the only way to go, IMHO. They work hard to keep lua simple and easily > auditable, so the security disadvantages should be minimized. Also, they > have several big lua deployments. They care a lot about its stability and > security. That might break at least one package that I maintain which will rely on dynamic lua libs in the next release, since it's C# and seems it cannot easily use the static one... or upstream just doesn't support that way, don't know enough about C# to say that. Even if they care about security, they don't seem to understand the problems that go with static libraries, distribution security and tracking of static libs consumers. Upstream of games-strategy/openra told me that it is not possible to use the static lib, since you would need to statically link mono to lua in order to avoid the dynamic loading within C# programs. And that is a no-go. More specifically, it is loaded by Eluant which might be used by more applications in the future. (In reply to Julian Ospald (hasufell) from comment #6) > Upstream of games-strategy/openra told me that it is not possible to use the > static lib, since you would need to statically link mono to lua in order to > avoid the dynamic loading within C# programs. And that is a no-go. > > More specifically, it is loaded by Eluant which might be used by more > applications in the future. Tell this to lua upstream and they will laugh on you. This is not their problem, and to be honest, this is not our problem, either. (In reply to Rafael Martins from comment #7) > (In reply to Julian Ospald (hasufell) from comment #6) > > Upstream of games-strategy/openra told me that it is not possible to use the > > static lib, since you would need to statically link mono to lua in order to > > avoid the dynamic loading within C# programs. And that is a no-go. > > > > More specifically, it is loaded by Eluant which might be used by more > > applications in the future. > > Tell this to lua upstream and they will laugh on you. Why? What is funny about it? I still don't see my previous questions answered. > This is not their problem Depends on how you define the opensource community. > and to be honest, this is not our problem, either. Then I am forced to create my own ebuilds for lua and do a lot of additional hacking to avoid file collisions and so on. On another note... for the security thing with static-only libs we could abuse subslots for that matter either by a) PV or even PF for all subslots of the lib b) just 1, 2, 3... subslots, only bumping it when a security bug has been fixed If lua upstream discourages dynamic linking, some project goes and *depends* on dynamic linked lua, the upstream have no reason to care about this project. I don't want to be offensive, honestly, but that guys probably started writing C code and contributing to open source before we birth. They know what they are doing, seriously. Lua is being build statically on big deployments for *years*. If you insist with this, they will probably keep ignoring you, as they seem to be doing right now, unfortunately. (In reply to Rafael Martins from comment #9) > If lua upstream discourages dynamic linking I see no reference whatsoever to that. If you have one, please show me. > Lua is being build statically on big deployments for *years*. Good for them. Other people build dynamic lua libs for years as well, without any problems, so I don't see an argument here. However, it's sad that this became a downstream-only standard, though. (In reply to Julian Ospald (hasufell) from comment #10) > (In reply to Rafael Martins from comment #9) > > If lua upstream discourages dynamic linking > > I see no reference whatsoever to that. If you have one, please show me. http://www.lua.org/manual/5.2/readme.html See the end of "installing lua" section. > > Lua is being build statically on big deployments for *years*. > > Good for them. Other people build dynamic lua libs for years as well, > without any problems, so I don't see an argument here. "we" build dynamic lua libs, then I know the pain myself. This is why I want to stick with what upstream recommends. The "without any problems" bit isn't accurate. > However, it's sad that this became a downstream-only standard, though. This isn't a standard anywhere, at least for lua. If people decide to dynamically build lua, they are on their own, from upstream POV. (In reply to Rafael Martins from comment #11) > (In reply to Julian Ospald (hasufell) from comment #10) > > (In reply to Rafael Martins from comment #9) > > > If lua upstream discourages dynamic linking > > > > I see no reference whatsoever to that. If you have one, please show me. > > http://www.lua.org/manual/5.2/readme.html > That is clearly a recommendation. For windows, they even recommend the opposite. That's why C# programs seem to expect it. I'm not going to waste my time on this discussion anymore. Not sure what I did here to deserve being ignored. Can comrel help with communication? I don't get what this bug is about. The linked tracker bug says we need to "document" modifications to avoid people depending on them. With a package that does not SHIP a pkgconfig file, how am I supposed to do this? Note that lua upstream decided not include a .pc file in the 5.2 release (while it's present in 5.1). I'm also confused about the amount of static vs dynamic linking discussion being mixed in here. Can you explain how that relates to having modified pkgconfig files? The way I see it, we have three problems confounded here: 1. Modified pkgconfig files. 2. Lua slotted and therefore multiple pkgconfig files. 3. Dynamic linkage and the hacked up build system All three are orthogonal, IMO. I'm taking patches for 3. And let me put this on the record: I don't see any other options for 1 and 2. I don't like the (currently masked) solution debian implemented and which I adopted, but I fail to see a better alternative as several upstreams including lua stated they don't plan or can't upgrade to lua-5.2 at the moment. (In reply to Julian Ospald (hasufell) from comment #14) > Not sure what I did here to deserve being ignored. Can comrel help with > communication? haha. oh god. I'm not ignoring you, I just find it pointless to keep discussing this here. I'm going to do whatever I can to stop building lua dynamically, due to everything already exposed, not just here. The point is: we are not going to support stuff unsupported upstream anymore (at least I won't, can't talk for mabi). If something is supported upstream, I will support as well. That means that, if you can get the patch that adds libtool support accepted upstream, we will have libtool as well, and for good. But upstream seems to ignore you, not me. Do you want comrel to help with communication with lua upstream? (In reply to Julian Ospald (hasufell) from comment #14) > Not sure what I did here to deserve being ignored. Can comrel help with > communication? Please read the comrel policy, then contact us if needed (In reply to Matti Bickel from comment #15) > I don't get what this bug is about. > Creating pkgconfig files downstream is wrong. > The linked tracker bug says we need to "document" modifications to avoid > people depending on them. With a package that does not SHIP a pkgconfig > file, how am I supposed to do this? > Not provide one at all. This is not a trivial thing, it causes cross-distro breakage and is discouraged. That's one reason why we don't have a pkgconfig.eclass... it's just wrong. Instead of following debian, we have to fix build systems that rely on broken debian packages. That can be done in most cases and that is what I have done so far. Debian is not upstream, so while I see the point of going nitpicky about what upstream does/thinks/likes, I don't see the point of adopting to random debian hackery. The rest we can certainly discuss somewhere else. (In reply to Rafael Martins from comment #16) > (In reply to Julian Ospald (hasufell) from comment #14) > > Not sure what I did here to deserve being ignored. Can comrel help with > > communication? > > I just find it pointless to keep > discussing this here. I'm going to do whatever I can to stop building lua > dynamically, due to everything already exposed, not just here. > I just didn't find any good arguments during the conversation, except that upstream doesn't encourage building shared libs on LINUX (but does encourage it on Windows). If you respond to valid arguments with "not going to waste my time on this discussion", then you can expect that it's perceived the way I did. (In reply to Julian Ospald (hasufell) from comment #19) > https://github.com/gentoo/devmanual.gentoo.org/commit/ > b0a519807f82c2190129dfa662922c8b061eb368 you are right wrt the pkgconfig file. we should fix it, but I'm not sure about what to do. it seems that mva is coming with an eselect module for lua, that can manage the pkgconfig file too, but 5.2 does not have any pkgconfig file, then we really need to wait a bit to decide what to do here. (In reply to Rafael Martins from comment #20) > (In reply to Julian Ospald (hasufell) from comment #19) > > https://github.com/gentoo/devmanual.gentoo.org/commit/ > > b0a519807f82c2190129dfa662922c8b061eb368 > > you are right wrt the pkgconfig file. we should fix it, but I'm not sure > about what to do. it seems that mva is coming with an eselect module for > lua, that can manage the pkgconfig file too, but 5.2 does not have any > pkgconfig file, then we really need to wait a bit to decide what to do here. ooops. s/that can manage/that maybe can manage/ (In reply to Rafael Martins from comment #20) > (In reply to Julian Ospald (hasufell) from comment #19) > > https://github.com/gentoo/devmanual.gentoo.org/commit/ > > b0a519807f82c2190129dfa662922c8b061eb368 > > you are right wrt the pkgconfig file. we should fix it, but I'm not sure > about what to do. it seems that mva is coming with an eselect module for > lua, that can manage the pkgconfig file too, but 5.2 does not have any > pkgconfig file, then we really need to wait a bit to decide what to do here. Has anyone bothered to bring this up on lua ML? If not, I'd say that's the first step (even if it's only to stand as proof that we tried). If that fails... for cmake build systems we should probably encourage upstream developers to use FindLua51.cmake and friends. for autoconf build systems we could try to work with autoconf maintainers to get a lua.m4 macro going? Not sure how realistic that is, though. The next step would be to remove all slots except :0. About eselect... I'm not sure if that's a good idea. Lua and Luajit serve the same purpose, but they are not unconditionally interchangeable. That's my experience from the few packages I maintain which make use of it. (afair luajit uses 32bit pointers everywhere which can also cause problems) For the packages that work with both, I just add a "luajit" USE flag if upstream supports it. You do realize that out of five distros (Fedora, Debian, Slackware, SuSe, Mandriva) I checked five ship a .pc file? Honestly, I see your point about maintainers being trapped by this. But if that's your only reason, I'd say us NOT shipping a pkgconfig interface hurts more. It'd be nice if we could get a follow-up on this thread: http://lua-users.org/lists/lua-l/2012-02/msg00748.html I'm kinda ashamed for not noticing the target and will probably rework the ebuild to use that instead of a custom file. We *still* need to modify it to be on par with other distributions. Let me repeat: removing the file or crippling it's functionality will IMHO paint Gentoo in a righteous and unpragmatic way. And I'm choosing a distribution that gets shit done[tm] any day. If you can persuade cmake and friends to switch to something else, that's cool with me and kudos to you. Let's revisit this bug after that happened. (In reply to Matti Bickel from comment #23) > You do realize that out of five distros (Fedora, Debian, Slackware, SuSe, > Mandriva) I checked five ship a .pc file? > > Honestly, I see your point about maintainers being trapped by this. But if > that's your only reason, I'd say us NOT shipping a pkgconfig interface hurts > more. > > It'd be nice if we could get a follow-up on this thread: > http://lua-users.org/lists/lua-l/2012-02/msg00748.html > > I'm kinda ashamed for not noticing the target and will probably rework the > ebuild to use that instead of a custom file. We *still* need to modify it to > be on par with other distributions. > > Let me repeat: removing the file or crippling it's functionality will IMHO > paint Gentoo in a righteous and unpragmatic way. And I'm choosing a > distribution that gets shit done[tm] any day. > > If you can persuade cmake and friends to switch to something else, that's > cool with me and kudos to you. Let's revisit this bug after that happened. I guess it's up to QA to decide whether this violation is authorized or not. Can QA please comment on this? [QA] (In reply to Julian Ospald (hasufell) from comment #24) > I guess it's up to QA to decide whether this violation is authorized or not. In my opinion, assuming you talk about downstream pkgconfig files; if upstream doesn't want to create/accept them, then this falls under the exception of an unavoidable fix (which should be discussed with other devs first) as per the devmanual part that you've referenced to in Comment #19. Should != must; though, I'm pretty sure that it was discussed with the relevant developers, but what does that matter if it is the only way out... An interesting idea to think about can be derived from the following fact: (In reply to Matti Bickel from comment #23) > You do realize that out of five distros (Fedora, Debian, Slackware, SuSe, > Mandriva) I checked five ship a .pc file? Distributions could cooperate to provide somewhat the same .pc file, or at least a quite similar one; extending on that, perhaps a central repository for upstream-divergent .pc files used by multiple distributions might be a nice idea. In extension to that; other libraries that depend on the package could start to use that hosted upstream-divergent .pc file, in the end the increased usage forces upstream to eventually acknowledge and/or add it to their repository. Hard to tell if that'll work, given it depends on other distributions stances to such a repository. If we want to discuss, we should move to the gentoo-dev ML. (In reply to Tom Wijsman (TomWij) from comment #25) > [QA] > > (In reply to Julian Ospald (hasufell) from comment #24) > > I guess it's up to QA to decide whether this violation is authorized or not. > > In my opinion, assuming you talk about downstream pkgconfig files; if > upstream doesn't want to create/accept them, then this falls under the > exception of an unavoidable fix (which should be discussed with other devs > first) as per the devmanual part that you've referenced to in Comment #19. > Not really. As per the ML discussion back then which produced that policy, unavoidable fixes were not defined as "just add a new .pc" file. It was quite the opposite, which is why pkgconfig.eclass was torn apart for good reason. An exception could be bug 410603 In addition, it is avoidable. > > but what does that matter if it is the only way out... > Exactly. It isn't. You can fix build systems instead. (In reply to Julian Ospald (hasufell) from comment #26) > Not really. As per the ML discussion back then which produced that policy, > unavoidable fixes were not defined as "just add a new .pc" file. It was > quite the opposite, which is why pkgconfig.eclass was torn apart for good > reason. An exception could be bug 410603 The discussion[1] has no mention of that; so, "unavoidable" is to be interpreted as unavoidable. The discussion also doesn't produce that policy; so, the policy was effectively made without pointing to a discussion source in its log message. [1]: http://thread.gmane.org/gmane.linux.gentoo.devel/81591 > In addition, it is avoidable. This bug tells me otherwise; if it were avoidable, it wouldn't be a disagreement. > > but what does that matter if it is the only way out... > > Exactly. It isn't. You can fix build systems instead. Or fix a distributed .pc files system instead, which is easier to maintain. (In reply to Tom Wijsman (TomWij) from comment #27) > The discussion[1] has no mention of that; so, "unavoidable" is to be > interpreted as unavoidable. Well, as I wrote the wording of the policy in devmanual, I can tell you that I did in no way mean what you interpret here. If we allow your kind of interpretation, then the policy is effectively completely useless, since I can pretty much interpret any hack as "unavoidable fix". In that case, I will suggest to remove that section of the devmanual, so we don't have broken policies lying around no one intents to follow. > > In addition, it is avoidable. > > This bug tells me otherwise; if it were avoidable, it wouldn't be a > disagreement. > That's completely illogical. Because a bug is open, there is no alternative solution? Err... wat? I just posted some. > > > but what does that matter if it is the only way out... > > > > Exactly. It isn't. You can fix build systems instead. > > Or fix a distributed .pc files system instead, which is easier to maintain. Your own QA policy disagrees, so I am unsure what warrants this exception of policy violation (it _IS_ one). So I am curious... why again does QA want to allow this? (not saying there are no exceptions whatsoever... but this hack isn't unavoidable) Not saying you need to convince me, but the current arguments don't make a lot of sense to me right now, except that it allows us to be lazy (which is in some circumstances even a good thing, not in this one, though). (In reply to Tom Wijsman (TomWij) from comment #25) > (In reply to Matti Bickel from comment #23) > > You do realize that out of five distros (Fedora, Debian, Slackware, SuSe, > > Mandriva) I checked five ship a .pc file? > > Distributions could cooperate to provide somewhat the same .pc file, or at > least a quite similar one; extending on that, perhaps a central repository > for upstream-divergent .pc files used by multiple distributions might be a > nice idea. > I'm sorry. I don't want to come off like someone who disagrees with everything, but this indeed sounds even more horrible than any previous suggestion. It will effectively create an elite midstream club only the major distros have any say in, disconnecting the end-user even more from upstream, probably causing less patches to go upstream since people realize we get "shit done" this way a lot easier... literally. and finally causing major pain for smaller distros, since they are not part of the club that decides about things. Hacks and patches will start to overlap long-term and cause breakage to the linux ecosystem we can't even imagine yet. Or... we probably can, because it is already happening on a smaller scale. The devmanual policy doesn't capture a discussion thread from what is visible. (In reply to Julian Ospald (hasufell) from comment #28) > That's completely illogical. Because a bug is open, there is no alternative > solution? Err... wat? I just posted some. There'll always be alternative suggestions; however, they are not yet a solution. > Your own QA policy disagrees, so I am unsure what warrants this exception of > policy violation (it _IS_ one). So I am curious... why again does QA want to > allow this? [...] The QA policy is an encouragement; so, it has no (dis)agreement value. https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Hacked_pkgconfig_files > It will effectively create an elite midstream club only the major distros > have any say in, [...] This sounds like the same set of control that a particular upstream has; in this specific case, anything is better than an upstream that doesn't do it at all. (In reply to Tom Wijsman (TomWij) from comment #29) > The devmanual policy doesn't capture a discussion thread from what is > visible. > > (In reply to Julian Ospald (hasufell) from comment #28) > > That's completely illogical. Because a bug is open, there is no alternative > > solution? Err... wat? I just posted some. > > There'll always be alternative suggestions; however, they are not yet a > solution. > Sorry, but this sounds like an empty phrase to me that tries to chat around my valid proposal of fixing build systems that rely on non-standard pkgconfig files... which is totally doable. > > Your own QA policy disagrees, so I am unsure what warrants this exception of > > policy violation (it _IS_ one). So I am curious... why again does QA want to > > allow this? [...] > > The QA policy is an encouragement; so, it has no (dis)agreement value. > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/ > Meeting_Summaries#Hacked_pkgconfig_files > I suggest to remove the devmanual policy then if QA overwrites it with a "do it or not" suggestions that effectively has no QA value at all. I'm confused of your understanding of "QA", frankly speaking (and I mean in the sense of enforcement here, not regarding a particular technical matter). I did expect something like "this is a valid exception, because of <actual argument following>...", but I got a "we have no particular opinion here we like to enforce... do it or not". > > It will effectively create an elite midstream club only the major distros > > have any say in, [...] > > This sounds like the same set of control that a particular upstream has; in > this specific case, anything is better than an upstream that doesn't do it > at all. No, you totally missed the point. Upstream is upstream (not midstream) and cannot create a divergence in itself, because it is... upstream. You want to create a distro-club that intentionally and randomly diverges from upstream without actually forking anything and confuses the linux ecosystem. That is so wrong, I will do anything I can to stop that. (but that is not even related to this bug anymore) (In reply to Julian Ospald (hasufell) from comment #30) > [..] chat around my valid proposal [...] It'll stay a proposal as long as you chat around in a random ignored bug. > I suggest to remove the devmanual policy [...] Feel free to file a new bug / agenda item for the QA team's consideration. > I'm confused of your understanding of "QA" This bug has no actual QA involvement; so, it are just maintenance thoughts... > [...] I got a "we have no particular opinion here we like to enforce... [...]" Exactly, as it currently stands this is up to the maintainer; until you elevate your proposal through the appropriate medium, starting with the gentoo-dev ML and ending with the gentoo-project ML to propose it to the Council. > [...] is upstream (not midstream) and cannot create a divergence [...] Libav is a divergence from FFmpeg; interesting, they are both upstreams. > You want to create a distro-club that intentionally and randomly diverges > from upstream without actually forking anything [...] Yes, it is so wrong; it is not random, as well as forks the pkgconfig files. > (but that is not even related to this bug anymore) Comment #25: If we want to discuss, we should move to the gentoo-dev ML. (In reply to Tom Wijsman (TomWij) from comment #31) > (In reply to Julian Ospald (hasufell) from comment #30) > > [..] chat around my valid proposal [...] > > It'll stay a proposal as long as you chat around in a random ignored bug. > > > I suggest to remove the devmanual policy [...] > > Feel free to file a new bug / agenda item for the QA team's consideration. > > > I'm confused of your understanding of "QA" > > This bug has no actual QA involvement; so, it are just maintenance > thoughts... > > > [...] I got a "we have no particular opinion here we like to enforce... [...]" > > Exactly, as it currently stands this is up to the maintainer; until you > elevate your proposal through the appropriate medium, starting with the > gentoo-dev ML and ending with the gentoo-project ML to propose it to the > Council. > > > [...] is upstream (not midstream) and cannot create a divergence [...] > > Libav is a divergence from FFmpeg; interesting, they are both upstreams. > > > You want to create a distro-club that intentionally and randomly diverges > > from upstream without actually forking anything [...] > > Yes, it is so wrong; it is not random, as well as forks the pkgconfig files. > > > (but that is not even related to this bug anymore) > > Comment #25: If we want to discuss, we should move to the gentoo-dev ML. No thanks, I fail to understand any of this. Asking questions to gain insight, as well as practicing to gain experience helps. As a user I have an interest in some of the points brought up in this bug. So, if y'all can bear with me:
a. Julian
1. How many packages would need to have their build systems pached?
2. How deep/invasive are those patches to other distributions?
(aka: How upstreamable are those?)
b. Everyone
1. What is the ongoing effort required to maintain a .pc file?
Thank you :)
Seemant
(In reply to Seemant Kulleen from comment #34) > How many packages would need to have their build systems pached? This bug is limited to only one file of one package; consider to use other communication mediums for more insight, this bug has received enough comments. > How deep/invasive are those patches to other distributions? Consider to ask the other distributions, only they can tell for sure. > What is the ongoing effort required to maintain a .pc file? The maintainers here appear to be able to maintain it. -- This matter is outside the QA team's scope and we have no further comments on it. (In reply to Seemant Kulleen from comment #34) > As a user I have an interest in some of the points brought up in this bug. > So, if y'all can bear with me: > > a. Julian > 1. How many packages would need to have their build systems pached? That is unknown yet and I did not have the time to test it. But... the offending lua versions (5.2+) seem to be hardmasked anyway, so we can easily do this. > 2. How deep/invasive are those patches to other distributions? > (aka: How upstreamable are those?) Not invasive at all. I have already submitted various such patches. It usually involves a simple fallback (if no pc-file is found use "-llua"). I have experience with doing this in cmake, autotools and plain Makefiles. This is nothing complicated. (In reply to Julian Ospald (hasufell) from comment #36) > Not invasive at all. I have already submitted various such patches. It > usually involves a simple fallback (if no pc-file is found use "-llua"). I > have experience with doing this in cmake, autotools and plain Makefiles. > > This is nothing complicated. Julian, thank you for your thorough response. Of the packages you've addressed, have you found upstreams to be generally receptive to the patches/fixes you submit? (In reply to Seemant Kulleen from comment #37) > (In reply to Julian Ospald (hasufell) from comment #36) > > > Not invasive at all. I have already submitted various such patches. It > > usually involves a simple fallback (if no pc-file is found use "-llua"). I > > have experience with doing this in cmake, autotools and plain Makefiles. > > > > This is nothing complicated. > > Julian, thank you for your thorough response. Of the packages you've > addressed, have you found upstreams to be generally receptive to the > patches/fixes you submit? Yes, since the patches trivial. |
