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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
