Re: package, package2, package3 naming-with-version exploit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


Vít
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux