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