package, package2, package3 naming-with-version exploit

[Vít Ondruch]

Dne 29.3.2013 14:42, Jan Zelený napsal(a):
> On 29. 3. 2013 at 10:29:01, Vít Ondruch wrote:
>> Dne 29.3.2013 02:09, Michael Scherer napsal(a):
>>> Le jeudi 28 mars 2013 à 17:45 +0100, Vít Ondruch a écrit :
>>>> If this problem was put first time on the table in 2002,
>>>> then there already passed 10 years of excuses.
>>> Or that in 10 years, we didn't found a proper solution that was
>>> sustainable.
>>>
>>>> It is interesting to see
>>>> that our competition can do much more with our technology then we do.
>>> Depend on what you define as "competition" and "our technology".
>>> While this could be anything, I will assume that you are speaking of
>>> debian, cause that's the only one that make sense to me.
>> This is what I am taking about:
>>
>> http://www.devconf.cz/slides/mls-pkgmgmt2.pdf
>> http://www.youtube.com/watch?v=FNwNF19oFqM
>>
>> They are using far more advanced techniques using RPM.
>>
>> Yes, I am aware that it is slightly of-topic, but that was generic
>> remark. The point is, they are trying, they probably also fails in
>> certain areas, they have to make prototypes and throw them out, they
>> have workaround missing features in RPM. But in comparison to Fedora,
>> they are doing something. We just collecting ideas, brainstorming, we
>> are afraid about security and so on. We are so afraid to fail that we
>> rather do nothing.
> I'm sorry but your statement is not entirely correct - we can do most of the
> things they can do, as we use libsolv in dnf.

The point is, libsolv can do it but they are missing support in RPM, 
therefore they must use some hacks.
>   We just choose not to use these features in Fedora.

Not sure who is "we" in this case, but as long as such advanced features 
are not supported on Fedora, it is impossible to install for example 
JRuby withou Ruby (MRI) on your system. Actually the only reason I know 
is that they are not supported by YUM yet, which I hope will be fixed by 
DNF soon.

>   That's actually one point that Michael made during his
> presentation IIRC. Also it's not true that we don't experiment with stuff and
> make prototypes. For example at this moment we are working on some pretty big
> changes in rpmdb, recently we added new plugin interface, improved selinux
> support, ... you name it.

I have no need to write plugin and have no issues with rpmdb, while I'd 
love to see the features menitoned in the presentation in Fedora. But if 
that plugin interface you mention will be possible to use to provide 
support for features mentioned in the presentation, then it is 
definitely improvement.

>
> The problem is that this particular request of yours is a bit different:
> You are asking us to completely change the way we work with package versioning
> in order to achieve something that is already achievable (admitting that not
> in the prettiest way). It is important to note that the change goes through
> the *entire* packaging stack, requiring multi-month effort of multiple people.
> Please try to understand that this is why we are trying to come up with
> different proposals solving at least parts of your problem.

Yes I understand that completely. That is not reason to not work towards 
right solution. You still sacrifice how long it takes and how much 
effort it takes, but you never leverage the effort which is invested 
into inefficiencies of current approach and you don't take into account 
the people who just gave up and they are already using different platform.

I just want you to accept the vision.


Vít