[katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello???

[corey welton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 25 Jul 2012 09:59:35 -0400 (EDT)
Og Maciel <omaciel at redhat.com> wrote:

> Sooo... Katello master now uses pulp-1.1.11-1.el6.noarch and we can
> no longer create i18n names repos... this *is* a change from previous
> behavior. What are you we going to do about it? Here's the start of
> the thread:
> https://www.redhat.com/archives/katello-devel/2012-June/msg00084.html

My 2c on all this:

If there's a requirement that something be "user-readable", there needs
to be consideration whether such a requirement can be universally
applied. Attempting to otherwise implement such a requirement in a
manner that can only be applied piecemeal will inevitably lead to
difficulty maintaining/fixing it later on down the road. 

In this case, it appears that due to limitations of yum, multibyte
characters cannot be used in repos.  At the same time, we have an
apparent requirement that repos be "user-readable".  

If multibyte characters cannot be used in repos, repos cannot, in all
cases, be considered "user-readable". Ergo, we have a flaw in the
requirement.

In the meantime, no longer supporting this results/will result in
regressions (initially in terms of bugs and subsequently in end-user
functionality) for products like katello which implement pulp --
particularly when, from a user's perspective, the front end should be
fully usable with little to no consideration as to how the data looks
on the backend.

While I agree with the notion of having a user friendly repo URL, I
also note the apparent (unfortunate) inability of yum to handle such
scenarios.  As such, I think the requirement needs to be
reconsidered.  If user-friendly repo names are desired, we could look
into other solutions. A mapping script, perhaps?  Who knows.

It's 2012, and globalization is a fact of life. The inability to handle
multibyte data in any app written in this era should be considered a
serious flaw.  To be hamstrung by a requirement of "user-readable" when
such a requirement cannot be applied universally seems to me to be a
misstep.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAlAQAooACgkQQISRiYQQweyN1gCeIkFM5BYvNSacO15djeIsbau4
BM8Anjd3vtCnL5MAFkj2plbQerWpcjzk
=ZAEc
-----END PGP SIGNATURE-----