Sunday 18 February 2007

tdebs - archive layout (updated)

(Some updates, see at the bottom).

Today I have moved the wiki page for TranslationDebs under i18n/TranslationDebs, since it seemed to be a more proper place.

I also read again my proposal, made some corrections and gave the layout proposal some thought. I realised that both compatible layout proposal and the incompatible layout proposal have disadvantages and/or are somewhat inconsistent with the current way the archive and apt work.

So I went on and added yet another proposal which should be some middle ground between the previous ones. Now I am not sure if this new one has any real benefits as opposed to the previous ones and I am not sure if I am still on the right track.

Now I need some help. I suggest interested people to look at the proposals and their advantages before answering the questions below.


So the questions are:
  1. which of the following archive layouts seems to be the "right" format?
    • f.d.o/debian/dists/DIST/SECT/l10n/LANG/
    • f.d.o/debian/dists/l10n/DIST/SECT/LANG/
    • f.d.o/debian/dists/DIST/l10n/LANG/SECT/
  2. Do we want a binary-$ARCH level at the end of this path? Is the lack of it an inconsistency? Do we want l10n material to be treated so differently? Do we consider the LANG some kind of replacement for $ARCH? Is there any or a significant part of l10n material that is arch dependent?
  3. Do we want to have a compatibility layer for older dpkg/apt, i.e do we want both an empty Packages and a Translations file in there?
  4. Which of the following looks the best for translation selection ? (note that the change of format leads one way or the other to incompatibilities)
    • deb-tdeb-$LANG http://ftp.debian.org/debian/ etch main
    • tdeb-$LANG http://ftp.debian.org/debian/ etch main
    • deb http://ftp.debian.org/debian/ etch main/l10n/$LANG
    • deb http://ftp.debian.org/debian/ etch l10n/$LANG/main/
  5. Does the package naming needs some rethinking since the current proposal doesn't allow translation installations to be installed via current dpkg implementation?
Update (20070221-1): Filipus Klutiero suggested that it would be nice not to need to add something in /etc/apt/sources.list . I agree, this is a very good idea. There was no suggestion how to do this, but I thought maybe /etc/default/locale can be used for translation selection via a new variable in there. I'll add this to the wiki page, too.

6 comments:

Anonymous said...

1. Why not debian/dists/DIST/SECT/l10n/ ? What would debian/dists/DIST/SECT/l10n/LANG/ contain?

5. "None". I wish there is no need to modify sources.list. The only lost advantage I see is that mirrors can't choose to not mirror a language, but that's minor and not worth such a complication of sources.list.

Thanks for your work. I really wish to see something like that implemented one day.

Filipus Klutiero

eddyp said...

1. Why not debian/dists/DIST/SECT/l10n/ ? What would debian/dists/DIST/SECT/l10n/LANG/ contain?

Only translations for the language LANG, so you'd have:

dists/lenny/main/l10n/nl - for Dutch translations
dists/lenny/main/l10n/fr - for French translations
dists/lenny/main/l10n/ro - for Romanian translations

Otherwise, what is the benefit of having the translations split from the main package, besides independent updates? ;-)

5. "None". I wish there is no need to modify sources.list. The only lost advantage I see is that mirrors can't choose to not mirror a language, but that's minor and not worth such a complication of sources.list.

Well, why wouldn't they? debmirror and rsync can handle excluding directories. Is just is not straight forward.

I would love not to be forced to modify sources.list, but I don't see other reasonable and controllable way to solve this.

Taking into account some environment variable from /etc/default/locale, maybe?

Thanks for your work. I really wish to see something like that implemented one day.

We are working on this, just have to get a reasonable draft and try a mock-up implementation.

Anonymous said...

1. Why not debian/dists/DIST/SECT/l10n/ ? What would debian/dists/DIST/SECT/l10n/LANG/ contain?

Only translations for the language LANG, so you'd have:

dists/lenny/main/l10n/nl - for Dutch translations
dists/lenny/main/l10n/fr - for French translations
dists/lenny/main/l10n/ro - for Romanian translations

I meant, which *files* would these directories contain?

Anonymous said...

"None". I wish there is no need to modify sources.list. The only lost advantage I see is that mirrors can't choose to not mirror a language, but that's minor and not worth such a complication of sources.list.

Well, why wouldn't they? debmirror and rsync can handle excluding directories. Is just is not straight forward.


Oh, right, I guess I was confused. Mirrors can indeed choose to not distribute some languages in either proposal, and there's no risk of breakage as long as official mirrors continue to mirror all languages.
That makes me think that it could be useful that mirrors allow to determine if they don't provide a translation for a language because there are none or because the mirror chose not to mirror it.
And to make APT warn the user on "apt-get updates" if a source doesn't mirror a default APT translation.

eddyp said...

1. Why not debian/dists/DIST/SECT/l10n/ ? What would debian/dists/DIST/SECT/l10n/LANG/ contain?

Only translations for the language LANG, so you'd have:

dists/lenny/main/l10n/nl - for Dutch translations
dists/lenny/main/l10n/fr - for French translations
dists/lenny/main/l10n/ro - for Romanian translations

I meant, which *files* would these directories contain?


s/Packages/Translations/ in here, and there you have it. That's what will be under dists/lenny/main/l10n/$LANG

The contents is described in the wiki page: see Format of the Translations file.

Anonymous said...

OK, then I agree with debian/dists/DIST/SECT/l10n/LANG/