On 29. 3. 2013 at 05:33:59, Bohuslav Kabrda wrote: > ----- Original Message ----- > > > On 28. 3. 2013 at 17:45:27, Vít Ondruch wrote: > > > Dne 28.3.2013 17:13, seth vidal napsal(a): > > > > On Thu, 28 Mar 2013 16:36:27 +0100 > > > > > > > > Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > >> <sarcasm> > > > >> Ah, are we going to distribute this howtos instead of binary > > > >> RPM's > > > >> now? It is 4 easy steps, everybody can handle it. May be we > > > >> could > > > >> convert whole distribution into bunch of how-tos. It would be > > > >> nice, > > > >> because how-to cannot have broken dependency for example. > > > >> </sarcasm> > > > > > > > > The above is not necessary and not going to help the > > > > conversation. > > > > > > > > Speaking only for myself the above just drowns out anything else > > > > you > > > > might say which could be helpful. > > > > > > > > Please refrain from comments like this in the future. You might > > > > find > > > > them cathartic but they come at a cost of your input being > > > > considered. > > > > > > > >> But please, Florian, seriously, I know all that. But still, that > > > >> is > > > >> not solution which fits everybody. People would need at least > > > >> some > > > >> level of understanding how things work. I want provide to all > > > >> potential users all the software available, no matter what > > > >> version of > > > >> library it uses. It has to work using packagekit or yum. I can > > > >> handle > > > >> more work with packaging, but I must have appropriate tools for > > > >> that. > > > >> > > > >> Yes, there is my famous case with multiple versions of Ruby > > > >> libraries, but there are other examples from other peoples in > > > >> this > > > >> thread and on other places. Please, let me to do my packaging > > > >> right, > > > >> i.e. use name and version as they are intended and don't abuse > > > >> package for some deficiency in RPM and YUM. > > > > > > > > You need to realize that this isn't a new problem nor is the ruby > > > > case > > > > particularly novel. > > > > > > > > > > > > I think the first time we encountered the problem on a non-kernel > > > > pkg > > > > wanting co-installation w/yum was back in 2002 or 2003. I'm sure > > > > it was > > > > even before that with up2date and rpm. > > > > > > > > > > > > The trouble is this - the solution you and others have suggested > > > > doesn't actually solve the problem it just moves it around. It > > > > also > > > > makes the situation of dep resolution and global updates that > > > > much more > > > > difficult. Which makes the management end of all this that much > > > > harder > > > > on the folks maintaining systems with these tools. > > > > > > > > I've not been working with the package-mgmt team in a while now > > > > but I > > > > do not think that any of the team is ignoring the issues - they > > > > are > > > > just far harder to balance packager needs, user needs and > > > > sysadmins > > > > needs that it would otherwise appear. > > > > > > > > > > > > -sv > > > > > > Sorry to say that, but neither my sarcasm nor your comment brings > > > anything new. If this problem was put first time on the table in > > > 2002, > > > then there already passed 10 years of excuses. It is interesting to > > > see > > > that our competition can do much more with our technology then we > > > do. > > > Well, I'm not going to comment any further on this particular > > > branch of > > > thread. > > > > No, please do. I'm honestly very curious who came up with a solution > > of our > > problem [1] that is better than ours, using our technology. That > > might > > actually be the first constructive information in this thread. > > > > And please don't think it's just 10+ years of excuses - we are not a > > bunch of > > guys who are just lazy to do this! > > > > Thanks > > Jan > > > > > > [1] The problem of simultaneous installation and *maintenance* of > > multiple, > > totally incompatible, versions of a single package. > > Just a quick note: > Correct me if I'm wrong, but it seems to me that you (and some other people) > don't distinguish between tooling for accommodating multiple versions of > packages and actually supporting these packages. To me, these are very > different aspects - should RPM/YUM be able to support multiple parallel > versions without the naming hacks? Yes. Should Fedora as a distro support > numbers of multiple versions of packages? In my opinion, we should try to > keep counts of supported packages minimal, as we do now. But that doesn't > really depend on _how_ we package the stuff. This is about providing the > tooling to people who actually want to maintain these more versions in > their private repositories or whatever. Believe me when I say that I distinguish those two areas very strictly. But the point I was making is that the technical solution of multiversion packaging has a potential to bring such a mess in spec files that they become unmaintanable and therefore the solution would be practically useless. I'm sorry to say that so far I haven't seen a single solution that would be acceptable for you while actually making packagers' lifes easier. Thanks Jan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
