packaging February 2008

packaging@lists.fedoraproject.org

32 participants
21 discussions

UTF-8 package names
by Toshio Kuratomi 05 Mar '08

05 Mar '08

Today the Packaging Committee began a discussion of whether package names should be allowed to contain the full range of Unicode characters (encoded as UTF-8) or be restricted to the ASCii subset. This is a bit of a contentious issue with the Packaging Committee members split but not yet set in stone about how to proceed. The main arguments seem to be: Pro Unicode: * Upstream knows best what name is most appropriate for their users. For us to change it locally in Fedora doesn't make much sense. * We allow Unicode in every other piece of the spec so why not in the package name? * We should be shaking out bugs in the handling of Unicode in our software rather than hiding issues with it. Pro ASCII: * Hard to type unicode package names, therefore it is a usability problem. * Is there a limit? Even if European letters are fine what about Kanji or Sanskrit? * Some pieces of software won't handle unicode package names and will need to be fixed. One package has been submitted for review with a unicode using package name and has some applicable comments: https://bugzilla.redhat.com/show_bug.cgi?id=261881 = Section of Packaging Committee Logs about Unicode Package Names = (09:32:18 AM) racor: banning non-ascii chars from package names (09:32:29 AM) spot: racor: eww. is someone actually doing that? (09:32:39 AM) f13: somebody did a + in a version I thought (09:32:40 AM) abadger1999: ivazquez sent something to the list. No actual draft but it was very simple. (09:32:47 AM) tibbs|h: spot: There's a review submitted. (09:32:49 AM) svahl left the room (quit: ). (09:32:51 AM) f13: but that doesn't count. (09:32:51 AM) rdieter: f13: inkscape, yeah, but fixed now. (09:32:59 AM) abadger1999: racor: What is the ratioinale? (09:33:01 AM) f13: tibbs|h: I bet its from nim-nim isn't it? (09:33:06 AM) racor: yes, there is a packaging under review ... <digging> (09:33:07 AM) tibbs|h: Yes, some fonts thing. (09:33:13 AM) spot: that seems like a no-brainer to me. (09:33:19 AM) abadger1999: spot: Why? (09:33:22 AM) tibbs|h: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=261881 (09:33:24 AM) buggbot: Bug 261881: medium, medium, ---, Nobody's working on this, feel free to take it, NEW , Review Request: Ã©colier-court-fonts - Ã‰colier court fonts (09:33:37 AM) spot: because xchat rendered that two different ways for me? (09:33:45 AM) spot: i don't even want to think about yum. (09:34:02 AM) abadger1999: spot: yum does need a fix. There's an open bug. (09:34:05 AM) f13: well, it would be good to test our infrastructure. (09:34:08 AM) tibbs|h: I don't really have an issue with non-ascii package names; we can't keep falling back on "our infrastructure sucks" forever. (09:34:11 AM) abadger1999: But I'm wondering why it's a bad thing. (09:34:21 AM) abadger1999: Shouldn't we consider places where utf-8 fails to be bugs? (09:34:44 AM) f13: non-ascii packages may have to be renamed if they ever show up in RHEL (09:34:53 AM) f13: I'm not sure how the RHN beast will handle it. (09:35:07 AM) spot: well, that is RHEL's problem. (09:35:10 AM) f13: yep (09:35:17 AM) f13: I'm not saying it should have much bearing on our decision (09:35:27 AM) spot: racor: are you against it for aesthetic reasons or technical ones? (09:35:31 AM) racor: IMO, the technical issues are minor, the real issue is usabilitsy (09:35:44 AM) racor: spot: neither usability (09:35:51 AM) tibbs|h: I always said that I won't review what I can't type. (09:36:05 AM) tibbs|h: But my inability to type that is my dysfunction. (09:36:11 AM) spot: well, i suppose that it would make it more difficult for english typists to install/use a package (09:36:23 AM) spot: but not impossible (09:36:25 AM) racor: consider: 90% of US users are not even able to type accented chars (09:36:27 AM) tibbs|h: But is that a reason to ban something? (09:36:47 AM) tibbs|h: I can't read German either, so let's kick out German translations. (09:36:53 AM) racor: 99.89% of Western folks are not able to type east asian chars (09:37:07 AM) f13: and 40% of all statistics are made up on the spot (09:37:20 AM) spot: my concern is when people start naming packages in kanji. (09:37:40 AM) racor: tibbs: right type the char ß (this is not a beta it's a sharp ss) (09:37:46 AM) spot: we already mandate that the spec file must be written in american english (09:38:11 AM) tibbs|h: racor: I already said I can't type those characters; I don't see what point your question serves. (09:38:28 AM) rdieter: spot: +1, I think that covers the case here then, no? (09:38:48 AM) tibbs|h: But I don't see the practical difference between ideograms and accented vowels, either. (09:38:57 AM) racor: tibbs: my point: anything outside of ascii not universal enough (09:38:59 AM) abadger1999: Yum bug: https://bugzilla.redhat.com/show_bug.cgi?id=261961 (09:39:01 AM) buggbot: Bug 261961: low, medium, ---, Jeremy Katz, NEW , Yum does not like non-ascii package names (09:39:14 AM) spot: well, technically we only say summary and description (09:39:18 AM) spot: "Please put personal preferences aside and use American English spelling in the summary and description." (09:39:18 AM) tibbs|h: Either we say "ASCII" or "UTF-8"; there's no point in anything in the middle. (09:39:39 AM) tibbs|h: We do not mandate that the entire spec be in English. (09:39:42 AM) f13: we already support non-ascii file names (09:39:56 AM) f13: so lon gas they are UTF-8 (09:40:00 AM) tibbs|h: We permit translated descriptions. (09:40:28 AM) rdieter: Can we at least agree that ASCII *SHOULD* be used? Not sure if it warrants a MUST. (09:40:40 AM) spot: yeah, i can support that ASCII should be used (09:40:43 AM) abadger1999: rdieter: I'm not sure I would agree with that. (09:40:51 AM) tibbs|h: I don't know if there's really a point. (09:41:05 AM) racor: package names!!! descr, etc. are legacy, convenience, (09:41:21 AM) tibbs|h: But we have rules about naming packages after things like the upstream tarball. (09:41:27 AM) abadger1999: I mean, nim-nim's point is also valid -- if the upstream name is non-ascii who are we to differ from upstream? (09:41:40 AM) rdieter: shrug, I'm ok with pushing the envelope here too. (09:41:58 AM) spot: if only to encourage people not to be stupid and spell things like this: ƁƎƗȂ (09:42:11 AM) f13: can we try this package as a trial run and see what all it breaks? (09:42:18 AM) racor: abadger1999: would you say the same if the package name was in cyrillian or turk? (09:42:28 AM) ***spot is getting pulled away (09:42:40 AM) spot: we'll have to pick this up next meeting (09:42:41 AM) spot: sorry. :( (09:42:52 AM) rdieter: f13: +1 :) (09:42:53 AM) abadger1999: racor: What does the package do? Is it a cyrillic font package? Is it something specific to Russian language speakers? (09:43:26 AM) abadger1999: spot: I think that needs to be addressed upstream. (09:43:35 AM) racor: abadger1999: not necessarily. Just author preference. (09:44:09 AM) abadger1999: racor: So that's the gray line for me. I think I'd say that we can try to influence upstream but it is an upstream decision. (09:44:09 AM) tibbs|h: We have a practical issue in any case, because our infrastructure doesn't properly support non-ASCII package names currently. (09:44:27 AM) racor: I could call a package: bärensößchen ... (09:44:33 AM) tibbs|h: Why not? (09:45:00 AM) tibbs|h: Looks like as good a name as anything else. (09:45:54 AM) racor: tibbs: except that most people would not be able to type it .... yum install <package-name> (09:46:09 AM) abadger1999: Copy and paste.... (09:46:19 AM) tibbs|h: Graphical interface. (09:46:25 AM) tibbs|h: Tab completion. (09:46:34 AM) tibbs|h: Learn to type German. (09:47:06 AM) racor: abadger1999, tibbs: that's laughable. (09:47:16 AM) tibbs|h: It's weird to see this argument backwards; usually the Americans are arguing for "nothing I can't understand" while the Europeans and Asians just laugh at the idiot luddites. (09:47:46 AM) tibbs|h: "Nothing in Fedora should use the metric system." (09:48:26 AM) racor: tibbs: learn to type Thai (09:49:15 AM) tibbs|h: I personally have no interest in doing so. (09:49:24 AM) tibbs|h: I don't see how that has any bearing on anything, though. -Toshio

14 32

%bits macro?
by Orion Poplawski 01 Mar '08

01 Mar '08

It might me useful to have a %bits macro automatically set to 32 or 64 as appropriate. Does this seem useful or is there a better way? I'm try to follow the following tip from http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks: #if __WORDSIZE == 32 #include "myautoconfig-32.h" #elif __WORDSIZE == 64 #include "myautoconfig-64.h" #else #error "Unknown word size" #endif So in my spec I want to move "myautoconfig.h" to "myautoconfig-32.h" (or 64) as appropriate. Would be nice to do: mv myautoconfig.h myautoconfig-%{bits}.h Thoughts? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

9 11

Perl package guidelines and filtering provides/requires
by Richard W.M. Jones 28 Feb '08

28 Feb '08

The Perl packaging guidelines are big on the need to filter provides and requires using some complex shell scripting: http://fedoraproject.org/wiki/Packaging/Perl I'm reviewing some Perl packages which don't do this. Furthermore I grabbed 10 approved Perl specfiles from CVS and only 2 of them (perl-Catalyst-Plugin-Static-Simple and perl-Class-MOP) actually did it. So is this packaging requirement real? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

2 3

are subpackages required for optional loadable libraries?
by John Dennis 27 Feb '08

27 Feb '08

Historically when a package includes optional support via a loadable module we've put the loadable module in a subpackage. For example a package might include a module supporting mysql so we would create a mysql subpackage which contains the mysql loadable module and the subpackage would require mysql. I presume the reason we've historically created these little subpackages is to deal with dependency issues. But suppose your package includes dozens of optional loadable modules does it still make sense to create dozens of subpackages? It starts to get unwieldly really quick. Is it permissible to skip all the subpackages, have the rpm include all the loadable modules, and put the onus on the user such that if they edit the main package's config file to load the mysql module it's up to them to make sure the mysql libraries are installed? Here's another issue: Suppose the package puts it's loadable modules (e.g. .so's) in it's own subdirectory for loadable modules. RPM's automatic dependency checking seems to completely miss all the external libraries needed at run time to load one of the modules and resolve all it's references. The net result is none of these external dependencies get picked up at all. Is that O.K.? How does one deal with that in a spec file? The answer to this question probably drives the answer to the first question. FWIW, the upstream spec file does not create a subpackage per loadable module. It does create a subpackage containing all the loadable modules. When we build the loadable module subpackage the resulting rpm is missing a lot of the external dependencies on external .so's. That's unfortunate but I'm thinking it's the only practical way to deal with it. Trying to factor out all the dependencies will be a packaging nightmare and it's going to be a headache for users trying to install, they're going to have to deal with lots of subpackages. At least with the scheme where all the loadable modules are in one subpackage you won't pull in stuff you don't want or need, but at the expense of not pulling in something you might need. Comments? -- John Dennis <jdennis(a)redhat.com>

6 11

handing files under $HOME directory on scriptlet
by Mamoru Tasaka 27 Feb '08

27 Feb '08

Hi. Now I am trying to review gnome-menu-extended. https://bugzilla.redhat.com/show_bug.cgi?id=426026 The main purpose of this package is to add KDE related submenus to GNOME panel menu. What I cannot judge for now is about the %postun scriptlet of the spec file: ------------------------------------------------------------- %postun rm -f /home/*/.local/share/applications/%{name}.desktop rm -f /root/.local/share/applications/%{name}.desktop -------------------------------------------------------------- Well, at least - if [ $1 = 0 ] ; then ..... ; fi is needed - This scriptlet cannot handle the case in which $HOME is not /home However the point is that this scriptlet is trying to handle (in this case delete) files under $HOME directory at %postun. Is this allowed? Regards, Mamoru

6 5

Re: recent TeX Live packaging changes
by Patrice Dumas 22 Feb '08

22 Feb '08

On Thu, Feb 21, 2008 at 02:17:07PM -0500, Matthew Saltzman wrote: > > On Thu, 2008-02-21 at 18:59 +0100, Jindrich Novy wrote: > > > > > Note that texlive-xdvi no more exists and it's now packaged separately > > in standalone xdvik package. > > Would it be possible to get a spin of xdvik that obsoletes the > tetex-xdvi package in Fedora 8 updates? yum keeps trying to replace my > xdvik with that tetex-xdvi package. Unless I am wrong, the problem is in the tetex-xdvi package that doesn't use versionned obsoletes. -- Pat

1 0

Re: recent TeX Live packaging changes
by Jindrich Novy 21 Feb '08

21 Feb '08

On Thu, Feb 21, 2008 at 02:17:07PM -0500, Matthew Saltzman wrote: > On Thu, 2008-02-21 at 18:59 +0100, Jindrich Novy wrote: > > > > > Note that texlive-xdvi no more exists and it's now packaged separately > > in standalone xdvik package. > > Would it be possible to get a spin of xdvik that obsoletes the > tetex-xdvi package in Fedora 8 updates? yum keeps trying to replace my > xdvik with that tetex-xdvi package. Sure, the update is in pending state with a request to push directly into stable updates: https://admin.fedoraproject.org/updates/F8/pending/tetex-3.0-44.8.fc8 It also contains fix for the unversioned obsoletes that causes obsoletion of newer xdvik. Jindrich -- Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/

1 0

Re: recent TeX Live packaging changes
by Jindrich Novy 21 Feb '08

21 Feb '08

On Thu, Feb 21, 2008 at 03:18:40PM -0300, Horst H. von Brand wrote: > Jindrich Novy <jnovy(a)redhat.com> wrote: > > Support for Japanese and East Asian languages is now moved to > > texlive-japanese, including bg5conv, sjisconv, etc. utilities which > > were formerly in texlive-latex. > > Shouldn't this be better called texlive-east-asian or some such? Makes sense. It is named texlive-japanese mostly for historical reasons, because only developers from Japan were actually interested in support for Japanese in Fedora TeXLive, particularly Matsuura Takanori who is behind the Fedora Japanese support. I haven't heard about anyone else using east Asian support unfortunatelly. Jindrich -- Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/

1 0

recent TeX Live packaging changes
by Jindrich Novy 21 Feb '08

21 Feb '08

Hi all, I made several modifications to TeXLive packaging recently so I want to make you aware of that, because some of your packages may need modifications to (Build)Requires, if you use documentation generation during build/your app uses TeXLive. The current list of subpackages that originates from TeXLive are: binaries: -------- dvipdfm dvipdfmx dvipng kpathsea kpathsea-devel mendexk texlive texlive-afm texlive-context texlive-doc texlive-dvips texlive-dviutils texlive-japanese texlive-latex texlive-utils texlive-xetex architecture independent bits: ----------------------------- texlive-texmf texlive-texmf-afm texlive-texmf-context texlive-texmf-doc texlive-texmf-dvips texlive-texmf-fonts texlive-texmf-japanese texlive-texmf-latex Major changes are that some stuff is moved out from main "texlive" package, mainly XeTeX and ConTeXt. Both now have their own packages. Note that also Metapost is moved to texlive-context. Motivation for packaging them separately is dependency of XeTeX on TECkit and dependency of ConTeXt to ruby, so that main texlive package no more depends on these. Packaging these bits separately is also natural as we should keep the baseline texlive package minimal. Support for Japanese and East Asian languages is now moved to texlive-japanese, including bg5conv, sjisconv, etc. utilities which were formerly in texlive-latex. Note that texlive-xdvi no more exists and it's now packaged separately in standalone xdvik package. Utilities that use Ghostscript are moved to texlive-utils to reduce dependency bloat, namely these: a2ping e2pall epstopdf gsftopk mf pdfcrop ps4pdf thumbpdf So please update your (Build)Requires in your packages if needed. TeXLive still contains virtual provides for teTeX, such as tetex-dvips, but better is to (Build)Require texlive-dvips. TeXLive packages now virtually provide: tex(tex) tex(latex) tex(dvips) tex(japanese) tex(context) So you can use these virual provides directly in order to not to be directly dependent on a particular TeX distribution in the future. Jindrich -- Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/

2 2

libcap and dbus?
by Roland Wolters 20 Feb '08

20 Feb '08

Hi list, The mass rebuild uncovered that there is something wrong with dbus: https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01685.ht… Since my few packages depend on dbus they of course fail: DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package dbus DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package avahi DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package sudo DEBUG util.py:261: Error: Missing Dependency: libcap.so.1()(64bit) is needed by package dbus-libs So what should I do? Rebuild them when a new dbus is out there? Or just sit and wait until someone else sorts it out? Roland -- What kind of man would put a known criminal in charge of a major branch of goverment? Apart from, say, the average voter? -- Terry Pratchett

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2008