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

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

 



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
-- 
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