Ticket #146 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

Renaming Django and related django-* packages to python-django-*

Reported by: bkabrda Owned by:
Priority: minor Milestone:
Component: Clarification Version:
Keywords: Cc:
Blocked By: Blocking:

Description

Hi, as it was originally reported in [1], the Django framework and its separately packaged plugins/extensions should be named python-django and python-django-*. The current state is, that Django itself is named Django (with capital D) and its extensions 'django-*' or 'Django-*'. Because Django and all of its extensions are Python libraries, they should be named python-django-* to conform with the Naming Guidelines [2] and also other Python frameworks (Pylons are named python-pylons, etc.). This has been also discussed at python-devel [3] and there have been no objections.

Therefore, we would like to ask fpc if:

1) This change could be approved.

2) If yes, it would be good to create a special section in Python guidelines, that would summarize how to name Django packages.

3) Personally, I think it might be good idea to have not only the provides that will come out of proper rename of the packages (e.g. package python-django - Provides: Django), but also some standardized provide, that would be mandatory, like django-foo = %{version}-%{release} (with lowercase d), so that the users will be able to install just by typing "yum install django-foo".

We would like to target F18 with this change.

Thank you for your comments.

Regards, Bohuslav "Slavek" Kabrda.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=736776

[2] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29

[3] http://lists.fedoraproject.org/pipermail/python-devel/2012-January/000335.html

Change History

comment:1 follow-up: ↓ 2 Changed 2 years ago by salimma

If the change is approved and lands for F-18, are we planning to perform the renaming for the stable releases as well, at least for those branches that track the same Django release?

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 2 years ago by bkabrda

Replying to salimma:

If the change is approved and lands for F-18, are we planning to perform the renaming for the stable releases as well, at least for those branches that track the same Django release?

The original plan was not to do that, because it may introduce some unpleasant inconsistencies, but it certainly is a point to discuss here (I, personally, would be against and leave all the changes just to F18).

comment:3 in reply to: ↑ 2 Changed 2 years ago by mrunge

Replying to bkabrda:

The original plan was not to do that, because it may introduce some unpleasant inconsistencies, but it certainly is a point to discuss here (I, personally, would be against and leave all the changes just to F18).

After thinking about it some time, I would strongly vote to change this in all releases. One reason is to have just one package/spec for all releases. Renaming shouldn't break dependencies, because renamed packages still provide the older ones (by name). I think, inconsistencies are bigger/will become bigger, if we're referring to package django-.... for releases f17 and older, or el5/6 and speaking of python-django-... for f18 and newer.

comment:4 Changed 2 years ago by spot

  • Status changed from new to closed
  • Resolution set to fixed

This change is acceptable to the FPC, but we are not mandating it at this time, and defer to the discretion of the Django maintainers. We also think that adding useful Provides as you propose will help users, should this change be made.

Vote: (+1:6, 0:0, -1:0)

comment:5 Changed 2 years ago by bkabrda

Hi guys, I would like to ask you, if you could add a paragraph about this naming convention and the django-foo provides to the Python packaging guidelines, so that if new packagers come, they will be able to see everything in the guidelines (and there will be a section that we can point them to).

Thanks!

Note: See TracTickets for help on using tickets.