Re: texlive-basic_2005-1_i386.changes REJECTED
On 29.11.05 Anthony DeRobertis ([EMAIL PROTECTED]) wrote: Norbert Preining wrote: Hi, allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. I really hope you've done this --- for all files --- before uploading. Also, there are several versions of the LPPL, at least one of which might have DFSG issues. If you allow me to drop a note: The license, which was used to release teTeX 2.0 in sarge, is still the old one, which was said to be problematic... H. -- Whatever doesn't succeed in two months and a half in California will never succeed. -- Rev. Henry Durant, founder of the University of California http://www.hilmar-preusse.de.vu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Peter Samuelson [EMAIL PROTECTED] wrote: [Frank Küster] Why do we need two packages containing the latex command, for example? Why do we need N packages that provide MTA functionality? That's not equivalent. An equivalent question would be more like why do we need N packages all containing the source code for exim and building a binary called /usr/sbin/exim? What I mean is, AFAICT, if you get past the packaging, tetex and texlive are the *same* source code and the *same* data - not just two different implementations of a similar interface. The source of teTeX is a *subset* of TeXLive's source, modulo versions. It will serve our users to be able to install, as a Debian package, the parts of TeXLive that are not included in teTeX. It would not do our users any good if we dropped teTeX right now and switched everything to TeXLive (especially Debian developers would be quite angry about the numerous FTBFS bugs, and nonresponsive maintainers who are overworked). I also think that teTeX is a long-term alternative (e.g. for people who want a reasonably sized, reasonably recent TeX system without thinking much about details, or for buildds). Alternatives would be to package all those extra things separately - unnecessary work, since the TeXLive developers already have done most of it; or to add it to teTeX Debian-specificly - this is simply not feasible, and would deteriorate teTeX's quality much (and also the quality of our maintenance and responsiveness). Becaues of the internal dependencies of a TeX system, it is not trivial to take out the things from TeXLive that are already in teTeX, and only package the rest. We will try to move things into this direction, but the way to go is to have a self-containing, working TeXLive system first, and then make it possible to use parts of it together with teTeX, step by step. Even then I think it would be better for our users to have both systems available as a whole, at the very least because of the (I hope hypothetical) concern that teTeX depends on a single person (Thomas Esser, the te in the name) and therefore might suffer from hypothetical personal problems in the future. So I would dearly hope that eventually tetex would evolve into little more than a set of metapackages that suck in stuff from texlive. That would mean dropping teTeX, and the metapackages would rather be transitional packages. Or do the existing tetex packages actually provide anything that could not be provided that way? Yes, they do: teTeX-3.0 had a public testing phase of about a year, while TeXLive is released yearly. I'm in favor of texlive being included in debian unstable (assuming license issues can be worked out), but I am not particularly in favor of having texlive and tetex coexist indefinitely. tetex is heavy enough that it should have to justify its continued existence (I mean as more than just a way to get all useful bits of TeX by listing just one package dependency) if texlive provides the same thing. I do agree with you here. Right now the justification for teTeX's existence simply is that it is established within Debian, and works. It might be that once the same is true for TeXLive, we find there's no justification left - or rather that there is one. Let's see. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
On Thu, Dec 01, 2005 at 09:51:34AM +0100, Frank Küster wrote: Peter Samuelson [EMAIL PROTECTED] wrote: [Frank Küster] Why do we need two packages containing the latex command, for example? Why do we need N packages that provide MTA functionality? That's not equivalent. An equivalent question would be more like why do we need N packages all containing the source code for exim and building a binary called /usr/sbin/exim? What I mean is, AFAICT, if you get past the packaging, tetex and texlive are the *same* source code and the *same* data - not just two different implementations of a similar interface. The source of teTeX is a *subset* of TeXLive's source, modulo versions. Then we definitely shouldn't need two copies of it! It will serve our users to be able to install, as a Debian package, the parts of TeXLive that are not included in teTeX. Then why can't TeXLive build binary packages: - tetex-bin, containing all the usual goodies it provides today - tetex-extras-double-plus-good, containing the new TeXLive stuff ? It would not do our users any good if we dropped teTeX right now and switched everything to TeXLive (especially Debian developers would be quite angry about the numerous FTBFS bugs, and nonresponsive maintainers who are overworked). They would be justifiably angry if you broke existing tetex build-dependencies; but if TeXLive is indeed a superset of teTeX, there is no reason at all why a switch to TeXLive should *require* breaking existing packages. I also think that teTeX is a long-term alternative (e.g. for people who want a reasonably sized, reasonably recent TeX system without thinking much about details, or for buildds). Sure sounds to me like this could be provided by careful division of the TeXLive contents between binary packages? Becaues of the internal dependencies of a TeX system, it is not trivial to take out the things from TeXLive that are already in teTeX, and only package the rest. Does this also apply to the suggestion of having a core tetex package built from TeXLive sources, plus a shell texlive package depending on it? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: texlive-basic_2005-1_i386.changes REJECTED
Steve Langasek [EMAIL PROTECTED] writes: The source of teTeX is a *subset* of TeXLive's source, modulo versions. Then we definitely shouldn't need two copies of it! Er, it sounds to me like what people are saying is: Yeah it would be great and desirable to have no duplication between tetex and texlive, and we're going to try to do that -- but it's _a lot of work_, and we'd like to approach that ideal in stages. That sounds pretty reasonable to me. -Miles -- `Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life' (from _A Pattern Language_) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Steve Langasek [EMAIL PROTECTED] wrote: On Thu, Dec 01, 2005 at 09:51:34AM +0100, Frank Küster wrote: Peter Samuelson [EMAIL PROTECTED] wrote: [Frank Küster] Why do we need two packages containing the latex command, for example? Why do we need N packages that provide MTA functionality? That's not equivalent. An equivalent question would be more like why do we need N packages all containing the source code for exim and building a binary called /usr/sbin/exim? What I mean is, AFAICT, if you get past the packaging, tetex and texlive are the *same* source code and the *same* data - not just two different implementations of a similar interface. The source of teTeX is a *subset* of TeXLive's source, modulo versions. Then we definitely shouldn't need two copies of it! Please go ahead and prepare a package of teTeX-3.0 from a version of TeXLive. Or don't do it - it's impossible, because there is no released version of TeXlive that corresponds to teTeX-3.0; probably there is not even a repository revision that corresponds to it; and maybe there is not even a corresponding version for every single file. Remember that both are a compilation of TeX-related programs, and if during testing of teTeX-3.0 Thomas Esser found a patch necessary for program x, he has for sure communicated it to x's upstream. But upstream might never have released a version of x that only contains that patch, but then a version of x with that patch plus further changes made it onto CTAN and into TeXLive. This is what I meant with modulo version. But even then it was an oversimplification by me to say that teTeX is a*subset* of TeXLives's sources. In fact there are the system maintenance scripts (like mktexlsr, fmtutil, updmap), which were originally written by Thomas Esser, but have subtle differences in TeXLive. The we don't need two copies argument would only be valid if we had separate maintainers of pdftex, latex, dvips, dvipdfm, ConTeXt, and all TeX and LaTeX input files, including fonts. All of them could then take their source from their upstream (either CTAN or a project homepage), coordinate with each other, and upload it to Debian when they have made sure everything works together. But this would mean to replace teTeX or TeXLive by a new TeX distribution, let's call it DebTeX. It's not feasible, and it doesn't make sense, and therefore we either have one TeX system with one set of sources, or two of them with two. I think we have shown enough good reasons to add TeXLive as a second TeX system; I agree with Josselin that we will have to reconsider whether we still need the smaller one, teTeX, once TeXLive has established itself within Debian. But let's not do this before we even tested TeXLive. It will serve our users to be able to install, as a Debian package, the parts of TeXLive that are not included in teTeX. Then why can't TeXLive build binary packages: - tetex-bin, containing all the usual goodies it provides today Because the source isn't there. It's a different version. There are differing design decisions between teTeX and TeXLive. This could be handled by patches, but who's going to do this? It would not do our users any good if we dropped teTeX right now and switched everything to TeXLive (especially Debian developers would be quite angry about the numerous FTBFS bugs, and nonresponsive maintainers who are overworked). They would be justifiably angry if you broke existing tetex build-dependencies; but if TeXLive is indeed a superset of teTeX, there is no reason at all why a switch to TeXLive should *require* breaking existing packages. Even updating teTeX to 3.0 revealed lots of bugs in Build-depending packages. Simply switching to TeXLive (and falsely calling it tetex) with its much less mature packaging would bring up more of them, plus its own bugs. Maybe I should put the argument differently: If we had a large TeX Strike Force, with lots of interested, coding-eager members, some of them partly payed for Debian work (as the X Strike Force has AFAIK), it might be feasible to do this switch (although I doubt it would be desirable). But we haven't; teTeX is currently maintained mainly by me as the only active DD, with some advice by Atsuhito Kohda and Julian Gilbey, and three non-DD's with SVN write access. One of them is also maintainer of TeX-live, and we all are doing this in our free time, nobody has a job connected with Debian work. I should be writing a paper right now instead of writing this mail I also think that teTeX is a long-term alternative (e.g. for people who want a reasonably sized, reasonably recent TeX system without thinking much about details, or for buildds). Sure sounds to me like this could be provided by careful division of the TeXLive contents between binary packages? You are wellcome to join us, helping to make the careful decisions, and implementing them. We are currently reworking the splitting of teTeX to
Re: texlive-basic_2005-1_i386.changes REJECTED
Le jeudi 01 décembre 2005 à 19:08 +0900, Miles Bader a écrit : Steve Langasek [EMAIL PROTECTED] writes: The source of teTeX is a *subset* of TeXLive's source, modulo versions. Then we definitely shouldn't need two copies of it! Er, it sounds to me like what people are saying is: Yeah it would be great and desirable to have no duplication between tetex and texlive, and we're going to try to do that -- but it's _a lot of work_, and we'd like to approach that ideal in stages. That sounds pretty reasonable to me. It sounds to me more like they are trying to keep both texlive and tetex in the archive, even in the long term. And *that* doesn't look reasonable. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: texlive-basic_2005-1_i386.changes REJECTED
Josselin Mouette [EMAIL PROTECTED] wrote: Le jeudi 01 décembre 2005 à 19:08 +0900, Miles Bader a écrit : Steve Langasek [EMAIL PROTECTED] writes: The source of teTeX is a *subset* of TeXLive's source, modulo versions. Then we definitely shouldn't need two copies of it! Er, it sounds to me like what people are saying is: Yeah it would be great and desirable to have no duplication between tetex and texlive, and we're going to try to do that -- but it's _a lot of work_, and we'd like to approach that ideal in stages. That sounds pretty reasonable to me. It sounds to me more like they are trying to keep both texlive and tetex in the archive, even in the long term. And *that* doesn't look reasonable. We are trying to *get* both into the archive; and I don't see how texlive could replace tetex for etch. But I agree with you that we should reconsider the question later. Personally, I assume there will be reasons to keep teTeX; whether they are strong enough compared to the archive bloat (and the dispersal of mantainer power) in the long run, that remains to be seen. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
Le jeudi 01 décembre 2005 à 11:56 +0100, Frank Küster a écrit : We are trying to *get* both into the archive; and I don't see how texlive could replace tetex for etch. But I agree with you that we should reconsider the question later. In this case, I have to agree with you. Personally, I assume there will be reasons to keep teTeX; whether they are strong enough compared to the archive bloat (and the dispersal of mantainer power) in the long run, that remains to be seen. I haven't seen any valid argument so far to keep twice the same source in the archive. And this isn't valid only for tetex. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: texlive-basic_2005-1_i386.changes REJECTED
Le mardi 29 novembre 2005 à 22:48 +0100, Norbert Preining a écrit : When did I ask you to make one single binary package? Even if I take five packages each of it will be bigger than anything else in Debian and completely unable to be handled. TeX is big, I'd expect packages to be big. How is it an issue? And there's a duplication of most TeX components. I hope there is some plan to merge those packages some day in the future. There is a lot of duplication in Debian, and up to now nobody has complaint. We are working on taking out and packagin *big* stuff (like font packages: lmodern, cm-super) so that they can be used with both teTeX and TeX live. The work on TeX live for Debian has actually led to this and an improved TeX Policy. Why do we need two packages containing the latex command, for example? When there is duplication, there is generally a reason behind it. We have several ping packages, but they all have different advantages and drawbacks. What does texlive's latex command bring that tetex' doesn't? And if it brings something, is there any point in using tetex? How can users know which package to install to get a working TeX system? Yes, a TeX system is *not* for the faint of heart! It is more complex and definitely bigger than anything in Debian. You cannot expect that a complete novice becomes a TeXnician by using the Debian packages. We take from the users the burden to care for formats, font maps and various other things. But flexibility has to be paid by complexity. That's live. Bullshit. TeX is not that complicated, and it is used by non-specialists. It is much simpler than a C++ development system, for example. But when someone installs g++, he gets a working C++ compiler. texlive-latex-base or texlive-foobar-stuff ? Worse, how can he know what Debian package to install when a .sty is missing? Will it be in This has been the same since many many years: How does one know that if you want to install pshan.sty you have to install the cjk package in Debian? And this does not happen only with TeX files, I often enough have to search packages.debian.org for a specific file. And we should try to avoid the need to rely on such tools instead of increasing it. Most issues of regular Debian users can be solved by installing the right package. But the problem is how they can know which package to install. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: texlive-basic_2005-1_i386.changes REJECTED
Joerg Jaspert [EMAIL PROTECTED] wrote: On 10488 March 1977, Frank Küster wrote: allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. I really hope you've done this --- for all files --- before uploading. Also, there are several versions of the LPPL, at least one of which might have DFSG issues. Note that teTeX is worse in this respect (#218105), and that having two (groups of) maintainers work on this will speed up resolving that bug, while rejecting texlive because it's copyright file is still not ideal will not. Just because something else is worse than this isnt a reason to allow another bad thing. That argumentation doesnt work. So far for the first part of my sentence. The second part means: With texlive in Debian, the chances to resolve #218105 for etch get realistic. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
Josselin Mouette [EMAIL PROTECTED] wrote: Le mardi 29 novembre 2005 à 22:48 +0100, Norbert Preining a écrit : There is a lot of duplication in Debian, and up to now nobody has complaint. We are working on taking out and packagin *big* stuff (like font packages: lmodern, cm-super) so that they can be used with both teTeX and TeX live. The work on TeX live for Debian has actually led to this and an improved TeX Policy. Why do we need two packages containing the latex command, for example? Why do we need N packages that provide MTA functionality? When there is duplication, there is generally a reason behind it. We have several ping packages, but they all have different advantages and drawbacks. What does texlive's latex command bring that tetex' doesn't? And if it brings something, is there any point in using tetex? Have you actually read the discussion following the ITP that you were pointed to? I don't like to repeat all that... - Both packages have different release cycles; teTeX has been released at about the same frequency as Debian, causing it to be outdated by one major version in woody and sarge, I don't remember potato. TeXLive has a planned release cycle of once per year, implying that chances are much bigger chance to get a recent pdfTeX (the executable behind the latex command) and LaTeX (the format behind it), along with more recent CTAN packages, into a Debian release. - teTeX, being smaller and less modular, will continue to be the system of choice for Build-Depends and for packages that depend on a TeX system because they use it for some internal purpose (e.g. creating PDF files from database content, from docbook sources,...). It is also better for people who simply want to use LaTeX (or TeX, or ConTeXt), but not bother about the newest, coolest CTAN packages. TeXLive, on the other hand, would be the system of choice for people that want to create (La,Con)TeX documents according to current state-of-the-art, and want to communicate and get or give support in TeX-related newsgroups and mailinglists (where do you have the latest version installed is usually one of the first questions). You can read more arguments in the ITP, see the link given earlier. How can users know which package to install to get a working TeX system? Yes, a TeX system is *not* for the faint of heart! It is more complex and definitely bigger than anything in Debian. You cannot expect that a complete novice becomes a TeXnician by using the Debian packages. We take from the users the burden to care for formats, font maps and various other things. But flexibility has to be paid by complexity. That's live. Bullshit. TeX is not that complicated, and it is used by non-specialists. It is much simpler than a C++ development system, for example. But when someone installs g++, he gets a working C++ compiler. So install teTeX. That's the collection of packages for the people who want to use TeX as non-specialists, like you do. TeXLive is for the others. This is not just a pet project of Norbert. For a long time, it has been a wish of the Debian users among the TeXlive developers and users to be able to install their TeXlive on their Debian system, without keeping teTeX or fiddle with equivs just to satisfy dependencies. I think that it would be to the benefit of our users (one group of them, actually) to have TeXLive in Debian. It's for the benefit of an other group to keep teTeX, and to keep it less modular (but with a better splitting between -base and -extra, as we currently discuss on debian-tetex-maint). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
[Frank Küster] Why do we need two packages containing the latex command, for example? Why do we need N packages that provide MTA functionality? That's not equivalent. An equivalent question would be more like why do we need N packages all containing the source code for exim and building a binary called /usr/sbin/exim? What I mean is, AFAICT, if you get past the packaging, tetex and texlive are the *same* source code and the *same* data - not just two different implementations of a similar interface. So I would dearly hope that eventually tetex would evolve into little more than a set of metapackages that suck in stuff from texlive. Or do the existing tetex packages actually provide anything that could not be provided that way? (Yes, I realise 'tetex' would be a misnomer at that point.) I'm in favor of texlive being included in debian unstable (assuming license issues can be worked out), but I am not particularly in favor of having texlive and tetex coexist indefinitely. tetex is heavy enough that it should have to justify its continued existence (I mean as more than just a way to get all useful bits of TeX by listing just one package dependency) if texlive provides the same thing. signature.asc Description: Digital signature
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Miles! On Die, 29 Nov 2005, Miles Bader wrote: PKG-doc PKG-doc-LANG (LANG is usually code like fr) Not sure, but I guess either just texlive-doc or texlive-doc-base. Done, texlive-doc-XX For the language stuff: Here is a problem as some languages packages are not *one* single language, but several (arabic, cjk, other). So would it be the best solution to have old:texlive-langX new:texlive--lang Existing usage seems a bit mixed; the main common point seems to be -LANG as a suffix. Some patterns are: PKG-LANG PKG-locale-LANG (this seems the most common) PKG-l10n-LANG(openoffice uses this) PKG-i18n-LANG(kde uses this) I will use the texlive-lang-longname due to the following reasons: . the packages are *not* about locales, l10n, nor i18n, it is about writing in this language, which can be done under any locale. It is no localization of TeX, but support for typesetting these languages . keep the longname out of the same reasons Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DUDOO (n.) The most deformed potato in any given collection of potatoes. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Jörg! On Mon, 28 Nov 2005, Joerg Jaspert wrote: Please comment, not only on the package naming, but also on the bin-to-source mapping. Hey, that looks ways better than the initial upload. Good work. :) And with 5 sources left its also much less then what I suggested. Thanks. I always try to incorporate suggestions. I could even go down to one source package, that would be easiest for me. Then we would have the TeX live iso image, add a debian subdir and build everything. But then again, who want's to upload 700M all the time. texlive-binaries-source 96M texlive-documentation-source57M texlive-languages-source37M texlive-base-source 78M texlive-extra-source172M Drop the -source from the source names i would say. Its clear what is source and what not. :) Ok. With those package sizes you should be *damn sure* that the stuff you/your sponsor uploads *really* works and doesnt have any simple errors. I assume you have a good testsuite for it? :) What do you count as simple errors? I install-remove-install-purge test most packages, run all of them on my working machine, go through some test in a chroot, build all in sid-chroot. And I hope that I can create a more automatic test suite later on. allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. Well, yes. To be honest: I looked for the real license before I wrote this. :) Take this as a pointer to a.) correct the catalog and b.) correct the header of the generated license.txt. And/Or whoever listed dfsg as a license in the first place. Please see Frank Küsters email to this topic. It is true that the TeX live license file is not perfect, but - with Frank's words - it is much better than the one in teTeX. We are working on fixing this. I have recently gotten write access to the TeX Catatolgues cvs repository so that I can feed back in corrections to the license descriptions. And if you take a look at the texlive ml at tug.org, I can assure you that Karl Berry is very eager in dropping everything from TeX live which has the slightest problem with being DFSG free. So, yes, you are right, there is much to do. But I hope this is not a barrier for getting it into Debian now. The Debian teTeX Team and I are working on clearing up the situation as good as possible. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- WINSTON-SALEM (n.) A person in a restaurant who suggest to their companions that they should split the cost of the meal equally, and then orders two packets of cigarettes on the bill. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Mon, 28 Nov 2005, Anthony DeRobertis wrote: texlive-binaries-source 96M --- texlive-basicbintexlive-base-bin texlive-binextratexlive-extrautils I'd suggest texline-extra-utils here, because (at least to me) extra ok. texlive-langindic texlive-lang-indic Shouldn't this go with languages, below? No, because in texlive-binaries-source there are all the arch-depend bins collected, while all the others are arch=all. This was done on purpose to reduce the load on the servers and do not make horrible file duplications. texlive-graphicstools texlive-graphicstools A hyphen would really be appreciated here, too. Probably because of st ok, done, too. texlive-langcjk texlive-lang-cjk Another language. As above. texlive-documentation-base texlive-base-doc I'm going to agree with the other poster: These should all be texlive-doc-FOO instead of texlive-FOO-doc (including the base one). Also done. texlive-languages-source37M Reasoning: We use names instead of codes as several of these packages include support for different languages/variants (greek: various versions of greek with different iso codes, ...). This makes them oddly different than the documentation packages. Could Yeah, this is true, but OTOH, these packages *are* different things. They are *not* localizations, they are actual tex input files supporting the *generation* of documents in these languages. They can be used under all locales, languages, countries, I want to stress this in the sense that I want to lure people into: Hey I don't need this. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- GALLIPOLI (adj.) Of the behaviour of a bottom lip trying to spit mouthwash after an injection at the dentist. Hence, loose, floppy, useless. 'She went suddenly Gallipoli in his arms' - Noel Coward. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining [EMAIL PROTECTED] writes: Existing usage seems a bit mixed; the main common point seems to be -LANG as a suffix. Some patterns are: PKG-LANG PKG-locale-LANG (this seems the most common) PKG-l10n-LANG(openoffice uses this) PKG-i18n-LANG(kde uses this) I will use the texlive-lang-longname due to the following reasons: . the packages are *not* about locales, l10n, nor i18n, it is about writing in this language, which can be done under any locale. It is no localization of TeX, but support for typesetting these languages . keep the longname out of the same reasons I agree -lang- is probably better than locale/l10n/i18n for the reason you state. However, why not use the official language codes where available (keeping the longname where there is no code)? They mean exactly what you want, and are widely used in debian package names -- ja doesn't mean Japanese locale or Japan the country, it means Japanese language. -Miles -- Suburbia: where they tear out the trees and then name streets after them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Miles Bader schrieb: I agree -lang- is probably better than locale/l10n/i18n for the reason you state. However, why not use the official language codes where available (keeping the longname where there is no code)? They mean exactly what you want, and are widely used in debian package names -- ja doesn't mean Japanese locale or Japan the country, it means Japanese language. No please. That would make confusion. Half of the packages named in one way, half of them named the other way. One thing please, either iso codes or longnames, not both. -- bye Joerg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Die, 29 Nov 2005, Joerg Jaspert wrote: I agree -lang- is probably better than locale/l10n/i18n for the reason you state. One thing please, either iso codes or longnames, not both. longnames, as I said. lang-longname for exactely this reason, not wanting to have different standards. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- BEALINGS The unsavoury parts of a moat which a knight has to pour out of his armour after being the victim of an araglin (q.v.). In medieval Flanders, soup made from bealins was a very slightly sought-after delicacy. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Joerg Jaspert [EMAIL PROTECTED] writes: No please. That would make confusion. Half of the packages named in one way, half of them named the other way. One thing please, either iso codes or longnames, not both. I think that's wrong -- there are very few exceptions, and those are _exceptions_ -- not single languages, but groups. It's a _good_ thing if they stand out, because indeed they are slightly weird. I have no idea what manju is, but african, arab, and cyrillic (and of course other) seem ill-defined compared to the rest (unless of course arab really means arabic, in which case ar could be used). Making them stand out is a useful property, not a flaw. Here's the list: african arab bg bo cs-sk cyrillic da de el en en-gb es fi fr he hr hu hy it ja ko la manju mn nl no other pl pt ru sv th uk vi -miles -- The automobile has not merely taken over the street, it has dissolved the living tissue of the city. Its appetite for space is absolutely insatiable; moving and parked, it devours urban land, leaving the buildings as mere islands of habitable space in a sea of dangerous and ugly traffic. [James Marston Fitch, New York Times, 1 May 1960] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Anthony DeRobertis [EMAIL PROTECTED] wrote: Norbert Preining wrote: allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. I really hope you've done this --- for all files --- before uploading. Also, there are several versions of the LPPL, at least one of which might have DFSG issues. Note that teTeX is worse in this respect (#218105), and that having two (groups of) maintainers work on this will speed up resolving that bug, while rejecting texlive because it's copyright file is still not ideal will not. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
First of all, let me cast my vote for -doc-XX rather than -XX-doc. It makes much more sense from a sorted package names point of view, which, as others have said, is important in package manager UIs. [Norbert Preining] texlive-documentation-czechslovak texlive-cs-doc Czech and Slovak are two different languages, 'cs' and 'sk'. You should check (no pun intended) to see if both languages are in there. Reasoning: We use names instead of codes as several of these packages include support for different languages/variants (greek: various versions of greek with different iso codes, ...). texlive-langafrican texlive-lang-african texlive-langarab texlive-lang-arab texlive-langarmenian texlive-lang-armenian Hmmm. Kind of ugly not to be able to use 2-letter ISO codes, but since many of these are groups of languages it probably is the best you can do after all. (Reminds me of my childhood, when people often used to ask me Do you speak African?) texlive-pstricks texlive-pstricks Is pstricks a single binary, akin to psmerge or psselect? If not, I'd hyphenate further, something like texlive-ps-tricks or texlive-ps-support. signature.asc Description: Digital signature
Re: texlive-basic_2005-1_i386.changes REJECTED
On Die, 29 Nov 2005, Peter Samuelson wrote: First of all, let me cast my vote for -doc-XX rather than -XX-doc. It Already implemented. [Norbert Preining] texlive-documentation-czechslovak texlive-cs-doc Czech and Slovak are two different languages, 'cs' and 'sk'. You should check (no pun intended) to see if both languages are in there. Hmm, there are, so I will go for texlive-doc-cs-sk Or are there other proposals? Hmmm. Kind of ugly not to be able to use 2-letter ISO codes, but since many of these are groups of languages it probably is the best you can do after all. (Reminds me of my childhood, when people often used to ask me Do you speak African?) Original I thought this also for the doc packages, but this was rejected by most of the posters. texlive-pstrickstexlive-pstricks Is pstricks a single binary, akin to psmerge or psselect? If not, It is a big package called pstricks. Thanks for the comments. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `How do you feel?' he asked him. bits of me keep passing out.' `We're safe,' he said. `Oh good,' said Arthur. in one of the spaceships of the Vogon Constructor Fleet.' this is obviously some strange usage of the word safe that I wasn't previously aware of.' --- Arthur after his first ever teleport ride. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Tue, 29 Nov 2005 17:01:25 +0100, Norbert Preining wrote: On Die, 29 Nov 2005, Peter Samuelson wrote: First of all, let me cast my vote for -doc-XX rather than -XX-doc. It Already implemented. [Norbert Preining] texlive-documentation-czechslovak texlive-cs-doc Czech and Slovak are two different languages, 'cs' and 'sk'. You should check (no pun intended) to see if both languages are in there. Hmm, there are, so I will go for texlive-doc-cs-sk Or are there other proposals? A small problem with this name is that it may suggest a lang-country combination (Czech as spoken in Slovakia), not two languages - compare eg. various -locale- or myspell- packages. texlive-doc-cs+sk maybe, or split it further? -- Michał Politowski Talking has been known to lead to communication if practiced carelessly. signature.asc Description: Digital signature
Non-DFSG TeXLive stuff [was: Re: texlive-basic_2005-1_i386.changes REJECTED]
Norbert Preining wrote: And if you take a look at the texlive ml at tug.org, I can assure you that Karl Berry is very eager in dropping everything from TeX live which has the slightest problem with being DFSG free. Hmm... in that case, I should mention my experience with XyMTeX, an organic chemistry LaTeX package included in TeX Live. Anyone else who wants to comment on non-DFSG-free components of TeX Live may as well follow up to this email. See Debian bug #304714 where I had originally filed an ITP, and the thread starting at http://lists.debian.org/debian-legal/2005/04/msg00408.html where I asked about the license. Unfortunately, when I emailed the author for a license clarification, his reply was as follows: I regret to say that only personal redistribution (except CTAN) is permissible. Thank your for your kind attention to XyMTeX. Sincerely Yours Shinsaku Fujita Just noticed that someone's opened an RFP bug #340555 for XyMTeX, so CC-ing this there. (To answer a question in the RFP, upstream's email address is fujitas (at) chem.kit.ac.jp if anyone wants to try convincing him to license it DFSG-freely.) regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-DFSG TeXLive stuff [was: Re: texlive-basic_2005-1_i386.changes REJECTED]
On Die, 29 Nov 2005, Kevin B. McCarty wrote: Hmm... in that case, I should mention my experience with XyMTeX, an organic chemistry LaTeX package included in TeX Live. Anyone else who wants to comment on non-DFSG-free components of TeX Live may as well follow up to this email. See Debian bug #304714 where I had originally filed an ITP, and the thread starting at http://lists.debian.org/debian-legal/2005/04/msg00408.html where I asked about the license. Unfortunately, when I emailed the author for a To my reading that thread didn't end in a conclusion that it is not acceptable. Furthermore, IMHO, if it would be *not* acceptable, then we would have to remove all, I repeat *ALL* LPPL licensed packages. I guess this is something we don't want to have in Debian. I regret to say that only personal redistribution (except CTAN) is permissible. Thank your for your kind attention to XyMTeX. This seems strange, I guess there was a misunderstanding, because the right to distribute the file unchanged is given in the file itself. Hard to say since we don't see the mail exchange with Shinsaku Fujita. So I don't see a serious problem here, only if you also want to remove most TeX package at all. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- The suit into which the man's body had been stuffed looked as if it's only purpose in life was to demonstrate how difficult it was to get this sort of body into a suit. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On 10488 March 1977, Norbert Preining wrote: Hey, that looks ways better than the initial upload. Good work. :) And with 5 sources left its also much less then what I suggested. Thanks. I always try to incorporate suggestions. I could even go down to one source package, that would be easiest for me. Then we would have the TeX live iso image, add a debian subdir and build everything. But then again, who want's to upload 700M all the time. No, not one single thing. Brrr. With those package sizes you should be *damn sure* that the stuff you/your sponsor uploads *really* works and doesnt have any simple errors. I assume you have a good testsuite for it? :) What do you count as simple errors? Stuff thats easy to find, like it breaks if you dpkg -i it, or simply doesnt run/work. -- bye Joerg Overfiend joshk: okay. I've manned a Debian booth before. I need to give you a quick training session. Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? pgpRc5Yi7Lq7T.pgp Description: PGP signature
Re: Non-DFSG TeXLive stuff [was: Re: texlive-basic_2005-1_i386.changes REJECTED]
Norbert Preining wrote: To my reading that thread didn't end in a conclusion that it is not acceptable. Furthermore, IMHO, if it would be *not* acceptable, then we would have to remove all, I repeat *ALL* LPPL licensed packages. I guess this is something we don't want to have in Debian. Yes, I figured that the LPPL could probably squeak by debian-legal (otherwise I wouldn't have ITP'ed XyMTeX), but I was more concerned about the somewhat contradictory-seeming reply from upstream. Possibly he has misinterpreted the meaning of the LPPL? But when there is a conflict between the written license in the package and the author's expressly stated wishes, it seems safest to assume that the latter are valid. This [upstream's reply] seems strange, I guess there was a misunderstanding, because the right to distribute the file unchanged is given in the file itself. Hard to say since we don't see the mail exchange with Shinsaku Fujita. I attach our entire email exchange (with some extraneous headers removed). I emailed once, to which he didn't reply; sent a follow-up email about a week later; and he finally gave the brief reply I quoted earlier. Apologies for the top-quoting in this exchange. I wasn't quite sure what to make of his reply so I didn't follow up further. Probably TeX Live or someone else distributing XyMTeX should do so, though. -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 ---BeginMessage--- Dear Dr. McCarty I regret to say that only personal redistribution (except CTAN) is permissible. Thank your for your kind attention to XyMTeX. Sincerely Yours Shinsaku Fujita === Kevin B. McCarty [EMAIL PROTECTED] wrote: Hello, I hope my previous email didn't come at a bad time for you - I realize it was probably unexpected. When you have a chance, I would be very grateful if you could look over my questions about XyMTeX licensing (attached again below for your convenience) and respond. I've found XyMTeX a very useful tool, and I would love to see the Debian Project distribute it, so that it might reach a larger audience. best regards, Kevin McCarty On 04/14/2005 06:10 PM, Kevin B. McCarty wrote: Dear sir: I just discovered XyMTeX today and I want to thank you for making such a useful LaTeX package available! I am using it for my doctoral thesis. To make it easier for others to install, I would like to package XyMTeX for the Debian GNU/Linux operating system (please check http://www.debian.org/ if you are not familiar with it). In order to do this I need to better understand some things about the license under which it is available. 1) In some of the files compressed in the xymtx402.lzh file, you have the following statement: % Copying of this file is authorized only if either % % (1) you make absolutely no changes to your copy, including name and % directory name % (2) if you do make changes, % (a) you name it something other than the names included in the % ``xymtex'' directory and % (b) you acknowledge the original name. % This restriction ensures that all standard styles are identical. Is it permitted for people to distribute modified versions of XyMTeX as well as copying it, as long as they follow conditions 2a and 2b? (In other words, do you intend copying to include redistribution?) 2) Some of the files (the PDFs, for instance) do not include a licensing statement, and there is no license that specifically encompasses every file. Under what license do you intend to distribute those files? 3) Some files, for instance doc402/jobdoc402/xymps402.tex, contain a statement This file is not permitted to be translated into Japanese and any other languages. May I ask the reasoning behind this? This restriction would not make it possible to distribute XyMTeX in the main section of software distributed by Debian; it would have to go into the so-called non-free section which is not as well-supported nor as much used. 4) Is it permitted to remove some files (for instance, the .dtx files) that will not be needed by most users, from a copy of XyMTeX that might be redistributed by someone? 5) Is it permitted to move some files (for instance the .pdf files) to a different directory, in a copy of XyMTeX that might be redistributed by someone? Users of Debian packages usually expect to find documentation in one specific location (not under texmf), for instance. 6) May people also distribute the file http://imt.chem.kit.ac.jp/fujita/fujitas3/xymtex/xym101/xymdvi/xymtex.pdf under the same license that you decide upon for my question (2)? Thank you very much for your time. I am looking forward to hearing your answers. Best regards,
Re: texlive-basic_2005-1_i386.changes REJECTED
On 10488 March 1977, Frank Küster wrote: allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. I really hope you've done this --- for all files --- before uploading. Also, there are several versions of the LPPL, at least one of which might have DFSG issues. Note that teTeX is worse in this respect (#218105), and that having two (groups of) maintainers work on this will speed up resolving that bug, while rejecting texlive because it's copyright file is still not ideal will not. Just because something else is worse than this isnt a reason to allow another bad thing. That argumentation doesnt work. -- bye Joerg Mal verlierst Du und mal gewinnen die anderen: Immer im Wechsel! pgpWCMD1mXNXv.pgp Description: PGP signature
Re: texlive-basic_2005-1_i386.changes REJECTED
Le lundi 28 novembre 2005 à 08:07 +0100, Norbert Preining a écrit : Im also not really happy with the current packaging, starting with the too heavy split of (source) packages. Ok, this can be dealt with. I thought it would be better to have a strict relation between source and bin packages, but where it was not possible. I'd go further, by asking why there must be so many binary packages. Of course, granularity is good, but too much granularity only means confusion. When I install a TeX system, I want a working environment without wondering if I need to install tex-foo or tex-bar. That's why I'm happy with the current naming scheme of tetex. A few packages, with clear names, and no one is lost. I know you're going to tell me there will be metapackages, and that I should just use them. But it also means even more packages, which aren't easily distinguishable from others. I've seen users not understanding why installing gnome-session doesn't bring a complete, working, GNOME session, and I'm afraid your naming scheme will lead to similar issues. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: texlive-basic_2005-1_i386.changes REJECTED
On Die, 29 Nov 2005, Josselin Mouette wrote: I'd go further, by asking why there must be so many binary packages. Of course, granularity is good, but too much granularity only means confusion. When I install a TeX system, I want a working environment without wondering if I need to install tex-foo or tex-bar. That's why Please read the thread following the ITP. If you want teTeX, install it. There is no way that we can make one binary package for close to 1Gb of software. (ITP: http://lists.debian.org/debian-devel/2005/06/msg00970.html) The granularity delivered by texlive is generally considered an advantage, but for those in search for a smaller solution with only few packages, there is tetex. I know you're going to tell me there will be metapackages, and that I No, there won't be. There is already texlive-latex-recommended and/or texlive-latex-base. If you apt-get/aptitude install this, you have a working system. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- JAWCRAIG (n. medical) A massive facial spasm which is brought on by being told a really astounding piece of news. A mysterious attack of jawcraig affected 40,000 sheep in Whales in 1952. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Die, 29 Nov 2005, Joerg Jaspert wrote: one source package, that would be easiest for me. Then we would have the TeX live iso image, add a debian subdir and build everything. But then again, who want's to upload 700M all the time. No, not one single thing. Brrr. Guess so. Would be fun, but for sure will break down the servers. What do you count as simple errors? Stuff thats easy to find, like it breaks if you dpkg -i it, or simply doesnt run/work. Ok, well, obvious. This is checked in chroot cage, in my working system, etc. Overfiend So, when's sarge going to be released? Shouldn't this be etch now! Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- WEEM (n.) The tools with which a dentist can inflict the greatest pain. Formerly, which tool this was dependent upon the imagination and skill of the individual dentist, though now, with technological advances, weems can be bought specially. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Le mardi 29 novembre 2005 à 22:16 +0100, Norbert Preining a écrit : Please read the thread following the ITP. If you want teTeX, install it. There is no way that we can make one binary package for close to 1Gb of software. When did I ask you to make one single binary package? The granularity delivered by texlive is generally considered an advantage, but for those in search for a smaller solution with only few packages, there is tetex. And there's a duplication of most TeX components. I hope there is some plan to merge those packages some day in the future. I know you're going to tell me there will be metapackages, and that I No, there won't be. There is already texlive-latex-recommended and/or texlive-latex-base. If you apt-get/aptitude install this, you have a working system. Aren't these metapackages? Anyway, you haven't even read what I've written. *sigh* How can users know which package to install to get a working TeX system? With tetex, everything is simple. Now with two tex package sets, one of them extremely granular, how can a user not aware about texlive, tetex and Debian internals know whether he has to install tetex-base, texlive-latex-base or texlive-foobar-stuff ? Worse, how can he know what Debian package to install when a .sty is missing? Will it be in texlive-math-extra, texlive-latex-recommended or texlive-formats-extra? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Josselin! On Die, 29 Nov 2005, Josselin Mouette wrote: There is no way that we can make one binary package for close to 1Gb of software. When did I ask you to make one single binary package? Even if I take five packages each of it will be bigger than anything else in Debian and completely unable to be handled. The granularity delivered by texlive is generally considered an advantage, but for those in search for a smaller solution with only few packages, there is tetex. And there's a duplication of most TeX components. I hope there is some plan to merge those packages some day in the future. There is a lot of duplication in Debian, and up to now nobody has complaint. We are working on taking out and packagin *big* stuff (like font packages: lmodern, cm-super) so that they can be used with both teTeX and TeX live. The work on TeX live for Debian has actually led to this and an improved TeX Policy. I know you're going to tell me there will be metapackages, and that I No, there won't be. There is already texlive-latex-recommended and/or texlive-latex-base. If you apt-get/aptitude install this, you have a working system. Aren't these metapackages? No! Why do you believe this. Anyway, you haven't even read what I've written. *sigh* I did *read* very well what you wrote. Please take a look at the packages before complaining: YOu wrote: I know you're going to tell me there will be metapackages, and that I should just use them. and I answered: No, there won't be. I think this is clear communication. And if you cannot take the time for taking a look wether texlive-latex-recommended is a metapackage or not, well. How can users know which package to install to get a working TeX system? Yes, a TeX system is *not* for the faint of heart! It is more complex and definitely bigger than anything in Debian. You cannot expect that a complete novice becomes a TeXnician by using the Debian packages. We take from the users the burden to care for formats, font maps and various other things. But flexibility has to be paid by complexity. That's live. What do you propose? 5 bin packages, 10? Where is the limit? And if you go below 5, the packages will *never* be accepted for the sole reason that they are t big. texlive-latex-base or texlive-foobar-stuff ? Worse, how can he know what Debian package to install when a .sty is missing? Will it be in This has been the same since many many years: How does one know that if you want to install pshan.sty you have to install the cjk package in Debian? And this does not happen only with TeX files, I often enough have to search packages.debian.org for a specific file. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- There are of course many problems connected with life, of which some of the most popular are `Why are people born?' Why do they spend so much of the intervening time wearing digital watches?' --- The Book. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On 10488 March 1977, Norbert Preining wrote: There is no way that we can make one binary package for close to 1Gb of software. When did I ask you to make one single binary package? Even if I take five packages each of it will be bigger than anything else in Debian and completely unable to be handled. Stuff like OOo for example isnt small either. There is a lot of duplication in Debian, and up to now nobody has complaint. Hey, im often enough bitching at people uploading the X version of $similar thing. There is also Multiple versions at http://ftp-master.debian.org/REJECT-FAQ.html. -- bye Joerg Contrary to common belief, Arch:i386 is *not* the same as Arch: any. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Jörg! On Mit, 30 Nov 2005, Joerg Jaspert wrote: There is no way that we can make one binary package for close to 1Gb of software. When did I ask you to make one single binary package? Even if I take five packages each of it will be bigger than anything else in Debian and completely unable to be handled. Stuff like OOo for example isnt small either. I didn't want to imply that there are no big packages, but Ooo has biggest component ooo-core with around 30Mb, while from the texlive packages we have one with around 85M, and several (9) in the aera of 10-50M. BUT: I don't imply that this is a quality criterium, not the least. I only want to give evidence that splitting texlive into several packages is necessary, in contrast to what Josselin proposed/suggested. There is a lot of duplication in Debian, and up to now nobody has complaint. Hey, im often enough bitching at people uploading the X version of $similar thing. There is also Multiple versions at http://ftp-master.debian.org/REJECT-FAQ.html. I am well aware of this faq. That's the reason why I try to single out as much packages as possible, especially the big ones (cm-super: 60M, lmodern: waiting for a maintainer, I have already created test packages for the prospective maintainer, cjk waiting, musixtex in discussion, etc) to get rid of duplicates. Furthermore we (debian tetex maint and I) are working on making the packages of tetex and texlive playing well together, i.e. that tetex users can install texlive packages. But this is for later on, as it requires some reworking of the TeX Policy, tex-common and some packages. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- POONA (n.) Satisfied grunting noise made when sitting back after a good meal. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Jörg, hi ftpmasters! On Mon, 28 Nov 2005, Norbert Preining wrote: binary. Better merge them into one texlive-source and build the different binary packages out of that one. You are left with 47 sources.. Similar things can be said for the language packs, merge the *27* to one and built the binaries out of that. Down to 21 sources. :) Ok, this is no problem. The .orig.tar.gz will be bigger, but I can merge the source packages without any problem. What do you thing about this scheme: (source package with size of the .orig.tar.gz, plus included binary packages) Would this be an acceptable solution for you? texlive-binaries-source 96M texlive-basicbin texlive-binextra texlive-fontbin texlive-htmlxml texlive-metapost texlive-omega texlive-pdfetex texlive-psutils texlive-ttfutils texlive-music texlive-langindic texlive-graphicstools texlive-langcjk texlive-documentation-source57M texlive-documentation-base texlive-documentation-bulgarian texlive-documentation-czechslovak texlive-documentation-dutch texlive-documentation-english texlive-documentation-finnish texlive-documentation-french texlive-documentation-german texlive-documentation-greek texlive-documentation-italian texlive-documentation-japanese texlive-documentation-korean texlive-documentation-mongolian texlive-documentation-polish texlive-documentation-portuguese texlive-documentation-russian texlive-documentation-spanish texlive-documentation-thai texlive-documentation-ukrainian texlive-languages-source37M texlive-langafrican texlive-langarab texlive-langarmenian texlive-langcroatian texlive-langcyrillic texlive-langczechslovak texlive-langdanish texlive-langdutch texlive-langfinnish texlive-langfrench texlive-langgerman texlive-langgreek texlive-langhebrew texlive-langhungarian texlive-langitalian texlive-langlatin texlive-langmanju texlive-langmongolian texlive-langnorwegian texlive-langother texlive-langpolish texlive-langportuguese texlive-langspanish texlive-langswedish texlive-langtibetan texlive-langukenglish texlive-langvietnamese texlive-base-source 78M texlive-basic texlive-context texlive-genericrecommended texlive-latex texlive-latexrecommended texlive-fontsrecommended texlive-pictures texlive-extra-source172M texlive-bibtexextra texlive-formatsextra texlive-genericextra texlive-mathextra texlive-plainextra texlive-latexextra texlive-latex3 texlive-fontsextra texlive-chemistry texlive-games texlive-pstricks texlive-publishers Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- MEATH (adj.) Warm and very slightly clammy. Descriptive of the texture of your hands after the automatic drying machine has turned itself off, just damp enough to make it embarrassing if you have to shake hands with someone immediately afterwards. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
BTW I think you need a few more hyphens in your package names -- stuff like texlive-langtibetan and texlive-fontsrecommended read much nicely as texlive-lang-tibetan and texlive-fonts-recommended. -miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining [EMAIL PROTECTED] wrote: What do you thing about this scheme: (source package with size of the .orig.tar.gz, plus included binary packages) Would this be an acceptable solution for you? [...] texlive-documentation-source 57M texlive-documentation-base texlive-documentation-bulgarian [...] texlive-languages-source 37M [...] texlive-base-source 78M texlive-basic [...] texlive-extra-source 172M texlive-bibtexextra Whether this is a good idea depends on a decision that, IIRC, we have not yet talked about: Will you only provide packages of the released version, or also of (usable) development versions? In the latter case, I think it would be a good idea to keep documentation sources and TeX input file sources together. Otherwise you'd have to rebuilt all packages from texlive-documentation-source and texlive-languages-source just because one language package was updated on CTAN and mirrored in TeXLive. And generally I wonder: Don't you generate most of the documentation from dtx files, and many input files from the same dtx files? Then why not build most documentation packages from the same source as the TeX input files? Or are the input files already included in the TeXlive repository in their extract version? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
On Nov 28 2005, Norbert Preining wrote: Hi Jörg, hi ftpmasters! Hi, Norbert, Jörg and others. Here is the opinion of a long time Debian luser (and DD wannabe), based on the naming that I am already used to with other packages. texlive-binaries-source 96M texlive-basicbin What about texlive-bin-base? texlive-binextra texlive-bin-extra? texlive-fontbin texlive-bin-font? texlive-langindic texlive-lang-indic? texlive-langcjk texlive-lang-cjk? texlive-documentation-source 57M texlive-documentation-base texlive-base-doc? texlive-documentation-bulgarian texlive-bulgarian-doc? texlive-documentation-czechslovak texlive-czechslovak-doc? (...) And similarly for all the others: texlive-language_here-doc? Or, perhaps: texlive-lang-language_here-doc (see this to avoid confusion with the packages below). texlive-languages-source 37M texlive-langafrican (...) texlive-langvietnamese What about: texlive-lang-african? (...) texlive-lang-vietnamese? With this scheme, the user would have two packages, possibly: texlive-lang-blah and texlive-lang-blah-doc and this would make it more or less obvious what the packages are about. What do you think? texlive-base-source 78M texlive-genericrecommended texlive-generic-recommended? texlive-latexrecommended texlive-latex-recommended? texlive-fontsrecommended texlive-fonts-recommended? texlive-extra-source 172M texlive-bibtexextra texlive-bibtex-extra? texlive-formatsextra texlive-formats-extra? texlive-genericextra texlive-generic-extra? texlive-mathextra texlive-math-extra? texlive-plainextra texlive-plain-extra? texlive-latexextra texlive-latex-extra? texlive-fontsextra texlive-fonts-extra? (...) texlive-chemistry texlive-games texlive-pstricks texlive-publishers Since there and others are generated by texlive-extra-source, it would perhaps be a possibility to append -extra to their names, so that the users already used to the Debian naming would automatically know that they are extra packages. Please sorry if I am talking nonsense here, but I'm sleep deprived. :-( Thanks for all your work, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining [EMAIL PROTECTED] wrote: On Son, 27 Nov 2005, Joerg Jaspert wrote: Looking at the texlive packages in NEW I have some comments for you, I can only support was Norbert has said here, no need to repeat it. Maybe two more things: The process of preparing Debian for having two TeX systems has very much improved the Policy Draft that we are currently writing (available in the tex-common package), and the packaging of teTeX (and texlive). I am sure that this is not a once-and-for-all-times process, but will continue to help us with critically rethinking our packages - and thus improve the quality of TeX in Debian. Second, Norbert is a TeXlive developer and a Debian user. He has become a Debian maintainer (and applied for DD) because he and other TeXlive developers and users wanted a simple way to install texlive in Debian, replacing teTeX while keeping dependencies in order. One should not assume that he will put only half as much effort into making teTeX more modular, as you have suggested, as he has put into the creation of the texlive Debian package. Instead, he and his users would be better served if he used the tex-common infrastructure that we have developed together to provide apt-get'able texlive packages from the texlive server. And I am sure that this situation would be much harder to handle, also for the teTeX maintainers and especially for maintainers of TeX-add-on packages or fonts, than if texlive was in Debian. allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. Please also note that, although TeXLive's copyright file might still be problematic, it is better than what teTeX has - see the bug #218105. And I fear that only the combined effort of Debian people caring for teTeX and for TeXLive will finally enable us to resolve this bug. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi all! On Mon, 28 Nov 2005, Miles Bader wrote: nicely as texlive-lang-tibetan and texlive-fonts-recommended. On Mon, 28 Nov 2005, Rogério Brito wrote: texlive-binaries-source 96M texlive-basicbin What about texlive-bin-base? As I said, it is true that I can arbitrary hyphens, but there was a decisison behind these names: Keeping the collections of TeX live (this is what users see when they use the installer) and the debian packages namewise in sync. I have no problem introducing different names, but only if I see good reasons other than I like it or it is usual like this. To me, the argument on name-sync collection-debiannames is strong enough to keep the current names. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- IBSTOCK (n.) Anything used to make a noise on a corrugated iron wall or clinker-built fence by dragging it along the surface while walking past it. 'Mr Bennett thoughtfully selected a stout ibstock and left the house.' - Jane Austen, Pride and Prejudice, II. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Frank! On Mon, 28 Nov 2005, Frank Küster wrote: texlive-languages-source37M texlive-base-source 78M texlive-extra-source172M Whether this is a good idea depends on a decision that, IIRC, we have not yet talked about: Will you only provide packages of the released version, or also of (usable) development versions? In the latter case, Irrelevant. I think it would be a good idea to keep documentation sources and TeX input file sources together. Otherwise you'd have to rebuilt all packages from texlive-documentation-source and texlive-languages-source just because one language package was updated on CTAN and mirrored in TeXLive. No, because a tpm is treated as unit, thus the documentation and source/input files are always in sync. the documentation-foobar packages provide documentation in the respective language if available. And generally I wonder: Don't you generate most of the documentation from dtx files, and many input files from the same dtx files? Then why No, I use what is in the depot of perforce texlive. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- You're bound to be unhappy if you optimize everything. --- Donald E. Knuth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining wrote: Hi all! On Mon, 28 Nov 2005, Miles Bader wrote: nicely as texlive-lang-tibetan and texlive-fonts-recommended. On Mon, 28 Nov 2005, Rogério Brito wrote: texlive-binaries-source 96M texlive-basicbin What about texlive-bin-base? As I said, it is true that I can arbitrary hyphens, but there was a decisison behind these names: Keeping the collections of TeX live (this is what users see when they use the installer) and the debian packages namewise in sync. I have no problem introducing different names, but only if I see good reasons other than I like it or it is usual like this. To me, the argument on name-sync collection-debiannames is strong enough to keep the current names. FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
[I've dropped some CCs...] Norbert Preining wrote: What about texlive-bin-base? As I said, it is true that I can arbitrary hyphens, but there was a decisison behind these names: Keeping the collections of TeX live (this is what users see when they use the installer) and the debian packages namewise in sync. I have no problem introducing different names, but only if I see good reasons other than I like it or it is usual like this. To me, the argument on name-sync collection-debiannames is strong enough to keep the current names. Well, Debian as a project has effectively standardized (by practice) on the hyphenation that has been suggested all over the place in this thread. Debian users will and should be able to expect a Debian-style package naming. Dismissing comments favoring this hyphenation - in unison - as expressions of personal taste doesn't really reflect the fact that consistency is a quality Debian users look for in packages. If you provide the TeX live names in the long description, people will be able to find stuff by the usual package search functions. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Rogério Brito [EMAIL PROTECTED] wrote: On Nov 28 2005, Norbert Preining wrote: Hi Jörg, hi ftpmasters! Hi, Norbert, Jörg and others. Here is the opinion of a long time Debian luser (and DD wannabe), based on the naming that I am already used to with other packages. texlive-binaries-source 96M texlive-basicbin What about texlive-bin-base? [...] And similarly for all the others: I think that keeping the package names the same as the texlive collection names would be a great benefit for the users. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining [EMAIL PROTECTED] wrote: And generally I wonder: Don't you generate most of the documentation from dtx files, and many input files from the same dtx files? Then why No, I use what is in the depot of perforce texlive. Right answer to my wrongly phrased question. The right question would have been: Do you keep ready-made documentation in the repository, or are the documentation files created at build-time from the dtx files?. Obviously, the answer is they are not created at build time. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
Thiemo Seufer [EMAIL PROTECTED] wrote: I have no problem introducing different names, but only if I see good reasons other than I like it or it is usual like this. To me, the argument on name-sync collection-debiannames is strong enough to keep the current names. FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. I agree with you; however this particular point should not be a reason for rejecting a package. It is clearly something that has to be synchronized with upstream, and it not of such severity that the package couldn't be accepted without such an upstream change. Especially if one notices that there won't be a new upstream release until autumn 2006. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
Thomas Viehmann [EMAIL PROTECTED] writes: Well, Debian as a project has effectively standardized (by practice) on the hyphenation that has been suggested all over the place in this thread. Debian users will and should be able to expect a Debian-style package naming. Dismissing comments favoring this hyphenation - in unison - as expressions of personal taste doesn't really reflect the fact that consistency is a quality Debian users look for in packages. If you provide the TeX live names in the long description, people will be able to find stuff by the usual package search functions. I'm not sure why the goal of exact correspondence with texlive names is important in the first place (if it's just because it's aesthetically pleasing, then obviously the same argument can be made from a Debian point of view as well). I assume that people seeing/using texlive-in-debian are more likely to be long-term Debian users rather than veteran texlive users, and will benefit both from more readable package names, and (as you say) from consistency with other debian packages. Note that there is a definite benefit to this sort of consistency -- I often do operations in aptitude by matching on package prefixes/suffix, e.g. everything matching -doc (or whatever). For programs, some sort of correspondence with texlive names might be useful, but that could be easily provide via other means (e.g. a mapping file, or perhaps virtual packages like texlive-collection-FOO). -miles -- /\ /\ (^.^) ()) *This is the cute kitty virus, please copy this into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Frank K.AN|ster [EMAIL PROTECTED] writes: I think that keeping the package names the same as the texlive collection names would be a great benefit for the users. Can you explain why it's important to keep the names _exactly_ the same? Renaming them to completely random names might put off or confuse some texlive users, but I think the changes suggested are not like that. -Miles -- $B+$i$r6u$K$7$F!?4$r3+$/;~!F;$O3+$+$l$k(B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Miles Bader [EMAIL PROTECTED] wrote: For programs, some sort of correspondence with texlive names might be useful, but that could be easily provide via other means (e.g. a mapping file, or perhaps virtual packages like texlive-collection-FOO). We already have a lot of real packages; no need to bloat the package list even further by providing lots of virtual ones. But on the other hand, you are all probably right, and it might actually be best to divert from upstream's names. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote: FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. As a user, I much prefer foo + libfoo + foo-doc-en + foo-doc-fr rather than foo + libfoo + foo-en-doc + foo-fr-doc To me the hierarchy tree package-sub-package-type-language/locale is much more natural than package-language/locale-sub-package-type Cheers Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Nov 28 2005, Frank Küster wrote: Rogério Brito [EMAIL PROTECTED] wrote: On Nov 28 2005, Norbert Preining wrote: texlive-binaries-source 96M texlive-basicbin What about texlive-bin-base? I think that keeping the package names the same as the texlive collection names would be a great benefit for the users. For which users exactly? Debian users? I would expect the fact of packaging a given piece of software to adapt it to the Debian system as a whole. For instance, many programs put their configuration files in places that are not acceptable for a Debian system (for instance, qmail comes to mind: it keeps is configuration files on /var/qmail/control), but the task of a Debian Developer is to adapt the package requirements to what a Debian system would look like (e.g., make all configuration of the package must be accessible via /etc). I understand that keeping the names in sync with what upstream provides is nice and here we have to make a choice between two standards. Which one to choose? I sincerely don't know. Oh, and even though some things aren't mandated, they are of course the basis for future policy if the practice is considered to be good enough (i.e., if it is a best current practice). BTW, I do agree with the fact that the naming alone (except for some disasterous things) is not a strong reason to reject an upload. Regards, Rogério Brito. P.S.: If, indeed, the package names for language things are changed, the proposal of having them use the ISO abbrevs would be quite nice. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Nov 28 2005, Thomas Viehmann wrote: Dismissing comments favoring this hyphenation - in unison - as expressions of personal taste doesn't really reflect the fact that consistency is a quality Debian users look for in packages. Agreed. Debian users look for consistency in the same way that development packages are called foo-dev, documentation packages are called foo-doc and some packages share content via foo-common packages, just to name a few things. If you provide the TeX live names in the long description, people will be able to find stuff by the usual package search functions. I think that this would be a nice suggestion for Norbert. If I were maintaining the packages, this would be something that I would actually adopt, to conform to the practices of both worlds. A good compromise, IMVHO. Of course, the packages are his and he decides how to name what. Regards, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Andrew Vaughan wrote: On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote: FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. As a user, I much prefer foo + libfoo + foo-doc-en + foo-doc-fr rather than foo + libfoo + foo-en-doc + foo-fr-doc To me the hierarchy tree package-sub-package-type-language/locale is much more natural than package-language/locale-sub-package-type It may look more natural, but it makes pattern matching harder (e.g. python-docutils is a false positive for the naive approach). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi all! (Taking out all the private email adr plus the other lists of the Cc and continuing only on debian-devel) On Mon, 28 Nov 2005, Miles Bader wrote: I assume that people seeing/using texlive-in-debian are more likely to be long-term Debian users rather than veteran texlive users, and will benefit both from more readable package names, and (as you say) from consistency with other debian packages. Note that there is a definite benefit to this sort of consistency -- I often do operations in aptitude by matching on package prefixes/suffix, e.g. everything matching -doc (or whatever). Ok, accepted. Let's go on and try to settle this: How would the layout go for documentation packages. Ok, for a documentation in language I take the XX code and generate old:texlive-documentation-x new:texlive-XX-doc But what to do with the texlive-documentation-base, should it become old:texlive-documenatation-base new:texlive-base-doc ? For the language stuff: Here is a problem as some languages packages are not *one* single language, but several (arabic, cjk, other). So would it be the best solution to have old:texlive-langX new:texlive--lang ? Finally a question concerning the package build from binaries-source: texlive-binaries-source 96M texlive-basicbin texlive-binextra texlive-fontbin texlive-htmlxml texlive-metapost texlive-omega texlive-pdfetex texlive-psutils texlive-ttfutils texlive-music texlive-langindic texlive-graphicstools texlive-langcjk Renaming some of them in the `obvious' way is in fact misleading: Take eg old:texlive-binextra and rename it to new:texlive-extra-bin Then most Debian users would expect a package texlive-extra and this one would provide only the binaries. But in binextra there are not the binaries for some extra package, there are just extra binaries including the necessary support files, so complete packages. To stress this fact: texlive-fontbin, texlive-binextra should be renamed to have decent names, but they are in some sense self contained packages containing binaries and the necessary support files, they are not of the usual -bin type packages in Debian, ie splitting out binaries from one package to have only small arch dep packages and one big arch indep package. If this changes anything in your idea on how the packages should be named, tell me, I am open to this. Otherwise, according to your comments, I would suggest texlive-base-bin texlive-extra-bin texlive-font-bin texlive-htmlxml texlive-metapost texlive-omega texlive-pdfetex texlive-psutils texlive-ttfutils texlive-music texlive-indic-lang texlive-graphicstools texlive-cjk-lang Would this be an acceptable naming scheme for all present? Also ftpmasters? Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LOUTH (n.) The sort of man who wears loud check jackets, has a personalised tankard behind the bar and always gets served before you do. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining wrote: [snip] For the language stuff: Here is a problem as some languages packages are not *one* single language, but several (arabic, cjk, other). So would it be the best solution to have old:texlive-langX new:texlive--lang ? Arabic is ar, IIRC. For groups of languages like cjk or indic it might make sense to split the packages further, or, if that's not feasible, use e.g. texlive-cjk-lang (but make sure the abbreviation is not ISO-style two-character). Finally a question concerning the package build from binaries-source: texlive-binaries-source 96M texlive-basicbin texlive-binextra texlive-fontbin texlive-htmlxml texlive-metapost texlive-omega texlive-pdfetex texlive-psutils texlive-ttfutils texlive-music texlive-langindic texlive-graphicstools texlive-langcjk Renaming some of them in the `obvious' way is in fact misleading: Take eg old:texlive-binextra and rename it to new:texlive-extra-bin Then most Debian users would expect a package texlive-extra and this one would provide only the binaries. But in binextra there are not the binaries for some extra package, there are just extra binaries including the necessary support files, so complete packages. Probably texlive-extra and texlive-fontutils then? In any case, there's not much need to search for executables only packages. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Quoting Thiemo Seufer [EMAIL PROTECTED]: Arabic is ar, IIRC. For groups of languages like cjk or indic it might make sense to split the packages further, or, if that's not feasible, use e.g. texlive-cjk-lang (but make sure the abbreviation is not ISO-style two-character). ISO-style can be two-character (ISO 639-1) or three-letter (ISO 639-2). The latter is IMHO more useful for TeX, as more languages have a code. Arabic is either ar or ara, Aramaic is arc, Apache is apa... cjk is currently not an ISO code, but it could be in the future. However, cjk is well-known, so ISO would be very stupid to use this code for anything else than zho-jpn-kor. Indic already has an ISO language code: inc. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining [EMAIL PROTECTED] wrote: How would the layout go for documentation packages. Ok, for a documentation in language I take the XX code and generate old:texlive-documentation-x new:texlive-XX-doc But what to do with the texlive-documentation-base, should it become old:texlive-documenatation-base new:texlive-base-doc ? I would say, yes, texlive-base-doc, because it is the doc package for texlive-base (or probably for the arch: all and arch: any packages with base in their name). It is not so much the basis of all texlive documentation. For the language stuff: Here is a problem as some languages packages are not *one* single language, but several (arabic, cjk, other). So would it be the best solution to have old:texlive-langX new:texlive--lang ? Here, I would take descriptive names - you wouldn't want to change the package name if cjk starts supporting an additional language. But as for arabic, isn't that *one* language? I'm not familiar with language vs. country codes, but I found a list of ISO 639 2- and 3-letter lanugage codes, where 'AR' or 'ara' stands for arabic. And the two-letter list is missing some languages with TeX support, e.g. Sorbian (wen). Otherwise, according to your comments, I would suggest texlive-base-bin texlive-extra-bin texlive-font-bin Why not texlive-bin-* in this case, if it fits better to the content? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: texlive-basic_2005-1_i386.changes REJECTED
Dear all! I have reworked the whole packaging naming and would like all of you again for comments: I collect here the binary packages by source package, and list first the old name, then the new name. For doc and lang I give some reasoning. Please comment, not only on the package naming, but also on the bin-to-source mapping. texlive-binaries-source 96M --- texlive-basicbintexlive-base-bin texlive-binextratexlive-extrautils texlive-fontbin texlive-fontutils texlive-htmlxml texlive-htmlxml texlive-metaposttexlive-metapost texlive-omega texlive-omega texlive-pdfetex texlive-pdfetex texlive-psutils texlive-psutils texlive-ttfutilstexlive-ttfutils texlive-music texlive-music texlive-langindic texlive-lang-indic texlive-graphicstools texlive-graphicstools texlive-langcjk texlive-lang-cjk texlive-documentation-source57M Reasoning: The documenatation is actually in a specific language, so we use the respective language code. texlive-documentation-base texlive-base-doc texlive-documentation-bulgarian texlive-bg-doc texlive-documentation-czechslovak texlive-cs-doc texlive-documentation-dutch texlive-nl-doc texlive-documentation-english texlive-en-doc texlive-documentation-finnish texlive-fi-doc texlive-documentation-frenchtexlive-fr-doc texlive-documentation-germantexlive-de-doc texlive-documentation-greek texlive-el-doc texlive-documentation-italian texlive-it-doc texlive-documentation-japanese texlive-ja-doc texlive-documentation-koreantexlive-ko-doc texlive-documentation-mongolian texlive-mn-doc texlive-documentation-polishtexlive-pl-doc texlive-documentation-portuguese texlive-pt-doc texlive-documentation-russian texlive-ru-doc texlive-documentation-spanish texlive-es-doc texlive-documentation-thai texlive-th-doc texlive-documentation-ukrainian texlive-uk-doc texlive-languages-source37M Reasoning: We use names instead of codes as several of these packages include support for different languages/variants (greek: various versions of greek with different iso codes, ...). texlive-langafrican texlive-lang-african texlive-langarabtexlive-lang-arab texlive-langarmeniantexlive-lang-armenian texlive-langcroatiantexlive-lang-croatian texlive-langcyrillictexlive-lang-cyrillic texlive-langczechslovak texlive-lang-czechslovak texlive-langdanish texlive-lang-danish texlive-langdutch texlive-lang-dutch texlive-langfinnish texlive-lang-finnish texlive-langfrench texlive-lang-french texlive-langgerman texlive-lang-german texlive-langgreek texlive-lang-greek texlive-langhebrew texlive-lang-hebrew texlive-langhungarian texlive-lang-hungarian texlive-langitalian texlive-lang-italian texlive-langlatin texlive-lang-latin texlive-langmanju texlive-lang-manju texlive-langmongolian texlive-lang-mongolian texlive-langnorwegian texlive-lang-norwegian texlive-langother texlive-lang-other texlive-langpolish texlive-lang-polish texlive-langportuguese texlive-lang-portuguese texlive-langspanish texlive-lang-spanish texlive-langswedish texlive-lang-swedish texlive-langtibetan texlive-lang-tibetan texlive-langukenglish texlive-lang-ukenglish texlive-langvietnamese texlive-lang-vietnamese texlive-base-source 78M texlive-basic texlive-base texlive-context texlive-context texlive-genericrecommended texlive-generic-recommended texlive-latex texlive-latex-base texlive-latexrecommendedtexlive-latex-recommended texlive-fontsrecommendedtexlive-fonts-recommended texlive-pictures texlive-extra-source172M texlive-bibtexextra texlive-bibtex-extra texlive-formatsextratexlive-formats-extra texlive-genericextratexlive-generic-extra texlive-mathextra texlive-math-extra texlive-plainextra texlive-plain-extra texlive-latexextra texlive-latex-extra texlive-latex3 texlive-latex3 texlive-fontsextra texlive-fonts-extra texlive-chemistry texlive-chemistry texlive-games texlive-games texlive-pstrickstexlive-pstricks texlive-publishers texlive-publishers Best wishes Norbert --- Dr. Norbert Preining preining AT
Re: texlive-basic_2005-1_i386.changes REJECTED
* Norbert Preining [EMAIL PROTECTED] [051128 11:20]: Dear all! Please comment, not only on the package naming, but also on the bin-to-source mapping. texlive-documentation-source 57M Reasoning: The documenatation is actually in a specific language, so we use the respective language code. texlive-documentation-basetexlive-base-doc texlive-documentation-bulgarian texlive-bg-doc texlive-documentation-czechslovak texlive-cs-doc texlive-documentation-dutch texlive-nl-doc texlive-documentation-english texlive-en-doc Best wishes Norbert In [1], Thiemo Seufer asserts that FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. I completely disagree. There is already precedent for using foo-doc-fr ordering of -doc-LANG: aptitude-doc-XX, udo-doc-XX, mdnkit-doc-XX, otrs-doc-XX, speechd-el-doc-cs (the -el- is emacs lisp, -cs is Czech), speech-dispatcher-doc-cs, lifelines-doc-sv, samba-doc-ja. I saw no examples of -XX-doc with XX a language. The most notable exceptions to PKG-doc-XX were doc-linux-XX and doc-debian-XX, but in these cases, you can consider 'doc-linux' and 'doc-debian' to be the package names, rather than documentation for the linux or debian package. And, the -XX still came after. I think -doc-XX is more natural, and I don't see why in [2] Thiemo said that it made pattern matching harder. In fact, I think it is easier to find documentation for the foo package with foo-doc; then you can easily see what languages are available. Suppose you speak German and are looking for documentation for package foo. You search for foo-doc; it lists several, but not foo-doc-de. However, it lists foo-doc-fr, and you speak French as a second language. Weeding out foo-docutils with the -doc-XX ordering is at least as easy as finding doc packages in all languages with Thiemo's ordering. I am not currently a texlive user, but as a Debian user, I would much prefer the current precedent rather than your proposed -XX-doc. ...Marvin [1] http://lists.debian.org/debian-devel/2005/11/msg01661.html [2] http://lists.debian.org/debian-devel/2005/11/msg01673.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Marvin Renich wrote: * Norbert Preining [EMAIL PROTECTED] [051128 11:20]: Dear all! Please comment, not only on the package naming, but also on the bin-to-source mapping. texlive-documentation-source57M Reasoning: The documenatation is actually in a specific language, so we use the respective language code. texlive-documentation-base texlive-base-doc texlive-documentation-bulgarian texlive-bg-doc texlive-documentation-czechslovak texlive-cs-doc texlive-documentation-dutch texlive-nl-doc texlive-documentation-english texlive-en-doc Best wishes Norbert In [1], Thiemo Seufer asserts that FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. I completely disagree. The point was about documentation and ukenglish. There is already precedent for using foo-doc-fr ordering of -doc-LANG: aptitude-doc-XX, udo-doc-XX, mdnkit-doc-XX, otrs-doc-XX, speechd-el-doc-cs (the -el- is emacs lisp, -cs is Czech), speech-dispatcher-doc-cs, lifelines-doc-sv, samba-doc-ja. I saw no examples of -XX-doc with XX a language. apt-cache pkgnames |egrep '(^doc-|-doc-|-doc$|-docs$)' should catch most documentation packages, it shows the -doc suffix as the most popular one. The most notable exceptions to PKG-doc-XX were doc-linux-XX and doc-debian-XX, but in these cases, you can consider 'doc-linux' and 'doc-debian' to be the package names, rather than documentation for the linux or debian package. And, the -XX still came after. I think -doc-XX is more natural, and I don't see why in [2] Thiemo said that it made pattern matching harder. In fact, I think it is easier to find documentation for the foo package with foo-doc; then you can easily see what languages are available. If you know you are intersted in foo, then it is easy anyway (apt-cache pkgnames instead of search for the purpose of this discussion): apt-cache pkgnames | grep '^foo.*-doc$' If the idea is to remove some documentation from a space-constrained system, a -doc suffix would be easier. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Monday 28 November 2005 19:36, Thiemo Seufer wrote: If you know you are intersted in foo, then it is easy anyway (apt-cache pkgnames instead of search for the purpose of this discussion): apt-cache pkgnames | grep '^foo.*-doc$' If the idea is to remove some documentation from a space-constrained system, a -doc suffix would be easier. I disagree. Most regular users use frontends like aptitude for package management that sort on package name. For those having related packages together and sorted on language makes most sense. Thus: foo-doc-lang For removing you can still egrep on '^foo-doc(-.*)?$'. For me, this is a specialized use case. Using a package management frontend is the normal use-case and should be an important factor in package naming. pgpitoKQFdKsg.pgp Description: PGP signature
Re: texlive-basic_2005-1_i386.changes REJECTED
On Tue, 29 Nov 2005 00:40, Thiemo Seufer wrote: Andrew Vaughan wrote: On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote: FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. Can you provide a reference/stats to back this up. (on sarge) $ apt-cache search doc |grep -e'-doc-[a-z][a-z] ' |wc -l 12 $ apt-cache search doc |grep -e'-[a-z][a-z]-doc ' |wc -l 5 Examination of the first set shows 1 false positive: gmt-doc-ps - PostScript docs for the Generic Mapping Tools The other 11 translated docs Examination of the second set shows: adduser-ng-doc - Documentation for AddUser-NG users gnome-db-doc - frontend to the GDA architecture for GNOME -- documentation gri-ps-doc - PostScript manual for gri, a language for scientific graphics. libinti-gl-doc - GtkGLExt bindings for Inti - shared libraries proj-ps-doc - PostScript docs for cartographic projection filters and library Also look at the output to apt-cache search firefox |grep locale This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. snip To me the hierarchy tree package-sub-package-type-language/locale is much more natural than package-language/locale-sub-package-type It may look more natural, but it makes pattern matching harder (e.g. python-docutils is a false positive for the naive approach). Probably any approach will yield false positives with naive search strings. However a few false positives don't matter in the typical use case of an interactive user searching for a package. Thiemo Package naming should be about what makes most sense to the users. For me, that means increasing specialisation (of package) means tacking additional suffixes on the end of the packagename. package foo. add a doc package foo, foo-doc add translated docs foo, foo-doc-en, foo-doc-jp, foo-doc-fr etc. (Regardless of which way is considered better, this sort of thing should be standardised and defined in policy IMO). Why do you need to filter for *-doc packages anyway? If you are looking for say Japanese doc packages, filtering on say *-doc-jp is as easy as *-jp-doc isn't it? If you want all doc packages, regardless of language/formatting/encoding, then filtering for doc-* and *-doc is not enough anyway. In order to find *-doc-html, *-doc-ps you need you need to add *-doc-* anyway. (i) You are going to miss packages which don't contain doc in the name. (eg ada-reference-manual, apt-dpkg-ref, docbook-defguide). (ii) In order to find *-doc-html, *-doc-ps etc packages you need to add *-doc-* anyway. (eg exim4-doc-html, exim4-doc-info, r-doc-html, r-doc-pdf etc. Note that renaming these to say exim4-info-doc suggests naive users that this is the documentation for the exim4-info package.) (iii) So you need to search for doc-* *-doc and *-doc-* anyway. eg. apt-cache search doc | grep -e'^doc-\|-doc-\|-doc ' or apt-cache search doc | grep -e'^doc-\|-doc\b' Cheers Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On 10487 March 1977, Norbert Preining wrote: I have reworked the whole packaging naming and would like all of you again for comments: WTH, what a thread. :) And its also *not* a flamewar. Is hell freezing? :) Please comment, not only on the package naming, but also on the bin-to-source mapping. Hey, that looks ways better than the initial upload. Good work. :) And with 5 sources left its also much less then what I suggested. texlive-binaries-source 96M texlive-documentation-source 57M texlive-languages-source 37M texlive-base-source 78M texlive-extra-source 172M Drop the -source from the source names i would say. Its clear what is source and what not. :) With those package sizes you should be *damn sure* that the stuff you/your sponsor uploads *really* works and doesnt have any simple errors. I assume you have a good testsuite for it? :) allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. Well, yes. To be honest: I looked for the real license before I wrote this. :) Take this as a pointer to a.) correct the catalog and b.) correct the header of the generated license.txt. And/Or whoever listed dfsg as a license in the first place. -- bye Joerg A.D. 1492: Christopher Columbus arrives in what he believes to be India, but which RMS informs him is actually GNU/India. pgpJBsKjeSP1X.pgp Description: PGP signature
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining wrote: texlive-binaries-source 96M --- texlive-basicbin texlive-base-bin texlive-binextra texlive-extrautils I'd suggest texline-extra-utils here, because (at least to me) extra and utils put together are hard to read. Possibly because au generally (always, maybe even) goes together as one sound in English. In general, hyphenated is far easier to read than concatenated, so I don't see a problem with prefering it. Just-try-reading-this-sentence vs. Justtryreadingthissentence. texlive-langindic texlive-lang-indic Shouldn't this go with languages, below? texlive-graphicstools texlive-graphicstools A hyphen would really be appreciated here, too. Probably because of st generally being one sound in English. Not to mention graphic stools has the same spelling. texlive-langcjk texlive-lang-cjk Another language. texlive-documentation-basetexlive-base-doc texlive-documentation-bulgarian texlive-bg-doc texlive-documentation-czechslovak texlive-cs-doc texlive-documentation-dutch texlive-nl-doc I'm going to agree with the other poster: These should all be texlive-doc-FOO instead of texlive-FOO-doc (including the base one). It'll make them all sort nicely in aptitude, and also makes them be found when the user searches (in aptitude) for texlive-doc. texlive-languages-source 37M Reasoning: We use names instead of codes as several of these packages include support for different languages/variants (greek: various versions of greek with different iso codes, ...). This makes them oddly different than the documentation packages. Could you maybe use ISO codes, either two or three letter, where possible? Its fairly clear that -lang-african can't do that, but almost all of them can. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Norbert Preining wrote: allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. I really hope you've done this --- for all files --- before uploading. Also, there are several versions of the LPPL, at least one of which might have DFSG issues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
How would the layout go for documentation packages. Ok, for a documentation in language I take the XX code and generate old:texlive-documentation-x new:texlive-XX-doc A bit of searching suggests the most common patterns are: PKG-doc PKG-doc-TYPE (TYPE is like html, ps, info etc.) PKG-doc-LANG (LANG is usually code like fr) But what to do with the texlive-documentation-base, should it become old:texlive-documenatation-base new:texlive-base-doc Not sure, but I guess either just texlive-doc or texlive-doc-base. For the language stuff: Here is a problem as some languages packages are not *one* single language, but several (arabic, cjk, other). So would it be the best solution to have old:texlive-langX new:texlive--lang Existing usage seems a bit mixed; the main common point seems to be -LANG as a suffix. Some patterns are: PKG-LANG PKG-locale-LANG (this seems the most common) PKG-l10n-LANG(openoffice uses this) PKG-i18n-LANG(kde uses this) I don't know if there's some technical nuance to the term locale which would make it inappropriate for texlive's usage, but it's the most common so would seem the best bet generally. [For stuff like cjk and arabic I'd just use the same namespace -- it seems very unlikely they'll ever conflict with a new language code.] Renaming some of them in the `obvious' way is in fact misleading: Take eg old:texlive-binextra and rename it to new:texlive-extra-bin Then most Debian users would expect a package texlive-extra and this one would provide only the binaries. I think PKG-bin-extra would be better. I think debian usage mostly agrees with the original texlive names except for the details of some common tags, e.g. doc instead of documentation and more hyphens. So how about as a start, just: sed -e 's/-documentation/-doc/' \ -e 's/-lang\(uages-\)*/-locale-/'\ -e 's/bin$/-bin/'\ -e 's/binaries/bin/' \ -e 's/basic-bin/bin/'\ -e 's/-basic/-base/' \ -e 's/\(extra\|recommended\)$/-\1/' \ -e s/armenian/hy/ -e s/bulgarian/bg/ -e s/croatian/hr/ \ -e s/czechslovak/cs-sk/ -e s/danish/da/ -e s/dutch/nl/ \ -e s/ukenglish/en-gb/ -e s/english/en/ -e s/finnish/fi/ \ -e s/french/fr/ -e s/german/de/ -e s/greek/el/ \ -e s/hebrew/he/ -e s/hungarian/hu/ -e s/italian/it/ \ -e s/japanese/ja/ -e s/korean/ko/ -e s/latin/la/ \ -e s/mongolian/mn/ -e s/norwegian/no/ -e s/polish/pl/\ -e s/portuguese/pt/ -e s/russian/ru/ -e s/spanish/es/\ -e s/swedish/sv/ -e s/tibetan/bo/ -e s/ukrainian/uk/ \ -e s/thai/th/ -e s/vietnamese/vi/ That gives this list: texlive-bin-source 96M texlive-bin texlive-bin-extra texlive-font-bin texlive-htmlxml texlive-metapost texlive-omega texlive-pdfetex texlive-psutils texlive-ttfutils texlive-music texlive-locale-indic texlive-graphicstools texlive-locale-cjk texlive-doc-source 57M texlive-doc-base texlive-doc-bg texlive-doc-cs-sk texlive-doc-nl texlive-doc-en texlive-doc-fi texlive-doc-fr texlive-doc-de texlive-doc-el texlive-doc-it texlive-doc-ja texlive-doc-ko texlive-doc-mn texlive-doc-pl texlive-doc-pt texlive-doc-ru texlive-doc-es texlive-doc-th texlive-doc-uk texlive-locale-source 37M texlive-locale-african texlive-locale-arab texlive-locale-hy texlive-locale-hr texlive-locale-cyrillic texlive-locale-cs-sk texlive-locale-da texlive-locale-nl texlive-locale-fi texlive-locale-fr texlive-locale-de texlive-locale-el texlive-locale-he texlive-locale-hu texlive-locale-it texlive-locale-la texlive-locale-manju texlive-locale-mn texlive-locale-no texlive-locale-other texlive-locale-pl texlive-locale-pt texlive-locale-es texlive-locale-sv texlive-locale-bo texlive-locale-en-gb texlive-locale-vi texlive-base-source 78M texlive-base texlive-context texlive-generic-recommended texlive-latex texlive-latex-recommended texlive-fonts-recommended texlive-pictures texlive-extra-source172M texlive-bibtex-extra texlive-formats-extra texlive-generic-extra texlive-math-extra
Re: texlive-basic_2005-1_i386.changes REJECTED
Hi Jörg, hi ftpmasters! (I take in debian-devel and debian-tetex-maint) I want to add some comments and questions: First, genesis of TeX live for Debian. This probably/hopefully answers the big ? of you: Following the ITP #312897 there was quite a bit of discussion on debian-devel on the topic why to include another TeX distribution, especially one that big. (ITP: http://lists.debian.org/debian-devel/2005/06/msg00970.html) There it is also stated that although TeX live is also a Live TeX distribution, it is also one of the most complete TeX system currently available. Furthermore it has the advantage that it is already split into smaller packages. Frank Küster, the maintainer of teTeX packages, summed up the advantages of having TeX live in Debian, explaining why it should be included (see http://lists.debian.org/debian-devel/2005/06/msg01103.html). The package splitting strategy was developed in cooperation with the TeX live upstream maintainers (via the [EMAIL PROTECTED] ml), and the teTeX maintainers (starting in late 2004 beginning of 2005): http://lists.debian.org/debian-tetex-maint/2005/01/msg00228.html It boils down to the following: In TeX live upstream there are packages (called tpm - tex package management) for each single package from CTAN. These tpms are grouped together in areas of interest called `collections'. In the discussion on the package split policy we came to the conclusion that it is not feasable to make one debian package from one tpm, that would be around 1000+ different packages. So we decided to go for transforming collections into debian packages. Now for your comments: On Son, 27 Nov 2005, Joerg Jaspert wrote: Looking at the texlive packages in NEW I have some comments for you, leaving alone my big ? why one wants to include basically a ctan mirror in debian / dupe many things with tetex, instead of simply putting more man-power/work into tetex if its not modular enough. See Franks comment above. Or: How many users of TeX packages have to go through the difficult process of installing packages by hand from the CTAN archive only to see that it is not working. It is not a completely trivial task, even for experienced sysadmins. To have a more or less complete TeX system in Debian is not a useless addition, it helps those working with TeX and more than the set included in teTeX. Looking at what I know from texlive its intended as a live thingie for users to play/start with tex? Is there such a huge userbase for this to No. Definitely not. Please see the web pages of texlive: http://www.tug.org/texlive. It is used on a wide range of platforms and operating systems, and normally is installed. It is *not* primary a live system (although the name suggests this). Im also not really happy with the current packaging, starting with the too heavy split of (source) packages. Ok, this can be dealt with. I thought it would be better to have a strict relation between source and bin packages, but where it was not possible. For example there are 19 documentation source packages, all building one binary. Better merge them into one texlive-source and build the different binary packages out of that one. You are left with 47 sources. Similar things can be said for the language packs, merge the *27* to one and built the binaries out of that. Down to 21 sources. :) Ok, this is no problem. The .orig.tar.gz will be bigger, but I can merge the source packages without any problem. Also I *suggest* to add a - after lang, so it reads lang-FOO, which is *IMO* easier. (Well, for all packages which dont have the additional -). The reason behind this decision was to have the package name reflecting the collection name, so that people using TeX live and using Debian see (+-) the same names. as you do now with 65. Yes, that makes the orig-tarballs bigger, but I dont think thats so much of a problem here. Ok, will do this. allrunes dfsg Please: Tell me its not true that the DFSG is used as a license there. As stated in the License file, this list was generated from the TeX Catalogue, which *can be wrong*! If you check the actual allrunes files, you see that it is LPPL. So for the further proceeding: I will generate a new set of .orig.tar.gz etc with a new source packages splitting scheme, trying to reduce the source packages as much as possible. Here a question: Theoretically I can make only *ONE* source package. That would make *many* *many* things *much* more easier. But, this would be rather big a .orig.tar.gz. In my understanding of the packaging process this is not what is wished, but please correct me! Especially I don't see the advantage of having such a big source package, fixes always would force a big rebuild of everything. For the package names I would prefer staying at the current names, as the relate to the TeX live collection names. But if ftpmasters would not accept, I will change. What further steps are necessary to get the OK from the
Re: texlive-basic_2005-1_i386.changes REJECTED
On Mon, 28 Nov 2005, Norbert Preining wrote: (I take in debian-devel and debian-tetex-maint) For completeness I attach the complete email of Jörg. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- WEST WITTERING (participial vb.) The uncontrollable twitching which breaks out when you're trying to get away from the most boring person at a party. --- Douglas Adams, The Meaning of Liff ---BeginMessage--- Hi Maintainer(s), Looking at the texlive packages in NEW I have some comments for you, leaving alone my big ? why one wants to include basically a ctan mirror in debian / dupe many things with tetex, instead of simply putting more man-power/work into tetex if its not modular enough. Looking at what I know from texlive its intended as a live thingie for users to play/start with tex? Is there such a huge userbase for this to include it (hey, its 600MB) into Debian? Im also not really happy with the current packaging, starting with the too heavy split of (source) packages. You have 65 of them right now. For example there are 19 documentation source packages, all building one binary. Better merge them into one texlive-source and build the different binary packages out of that one. You are left with 47 sources. Similar things can be said for the language packs, merge the *27* to one and built the binaries out of that. Down to 21 sources. :) Also I *suggest* to add a - after lang, so it reads lang-FOO, which is *IMO* easier. (Well, for all packages which dont have the additional -). To not repeat too much: The same goes for all different source packages that are splitted into recommended/extra/whatever. I think you can end up with less than 20 source packages, building up the same functionality as you do now with 65. Yes, that makes the orig-tarballs bigger, but I dont think thats so much of a problem here. Oh, if I go and read the included Licenses.txt i see they have the following listed: # The licenses codes as described on # http://www.ctan.org/tex-archive/help/Catalogue/licenses.html # are # DFSG free licenses: # dfsg Debian Free Software Guidelines # artisticPerl Artistic License [... and so on] and a bit down: allrunes dfsg (and more package) Please: Tell me its not true that the DFSG is used as a license there. Note: Feel free to move the discussion to the -devel list if you want. -- bye Joerg === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. ---End Message---
