[REQUEST] Move glibc-i18n from L to A packages series in Slackware-next

Didier Spaier · 11-16-2013, 10:35 AM

Rationale:

Any localization needs glibc-i8n
This package includes only locale definitions, no library strictly speaking
It is needed on the console as well as under X
Yes it's big (116M expanded on 14.1), but people wanting a minimum set of packages can easily remove it, or simply not install it (if they don't want it they won't do a full installation anyway).

GazL · 11-17-2013, 06:29 AM

I honestly don't see the point. The a,ap,l and n disksets are all a bit of an arbitrary mess anyway, especially so the 'n' set.

Didier Spaier · 11-17-2013, 07:03 AM

Quote:

Originally Posted by GazL

I honestly don't see the point. The a,ap,l and n disksets are all a bit of an arbitrary mess anyway, especially so the 'n' set.

The point is: as I see it, a,ap,n make together kind of a "base Slackware". Currently you can't have a localized base Slackware.

GazL · 11-17-2013, 07:43 AM

I was probably a little too terse there. My point was that as the glibc-2 package itself is only a little bigger than the i18n stuff, you might as well move the entire glibc-2 package into the 'a' set if that is your goal, and do away with the need for a separate glibc-i18n and glibc-zoneinfo (I believe glibc-2 contains both of these anyway). I don't think moving just glibc-i18n in isolation makes sense.

I'm not opposed to your goal, infact I've argued for a 'base' set before. The disksets are long overdue a reorganisation. They made sense 20 years ago, but not today.

Didier Spaier · 11-17-2013, 08:26 AM

glibc-zoneinfo (3.1 M) contains the timezone database and the timeconfig utility
glibc-i18n (116 M) contains the locale files
glibc-2 (144M) contains he GNU C libraries and header file, plus the same locale files as glibc-i18n (but not the timezone database). That seems logical as these files are (a relatively independent) part of glibc-2.

But I don't see the rationale for moving the whole glibc-2 to a, as someone installing a but not l won't be able to use the libraries and header files anyway.

GazL · 11-17-2013, 09:15 AM

The rationale is that other than the headers, the majority of glibc would already be in 'a', after i18n was moved, zoneinfo is small, and probably should be included in the minimal 'a' set anyway for the same reasons as you specify for i18n, and the solibs are already included. (edit: I was working under the impression that libc.so was included in aaa_elflibs, I hadn't realised glibc-solibs was already in the 'a' set - got it into my head it was in 'l', my mistake)

I take your point about the headers. Then perhaps what I should have said is glibc-solibs, glibc-zoneinfo, and glic-i18n belong in the 'a' set, and the profile libraries and glibc-2 (which could have the duplicates stripped out of it, and arguably also include kernel-headers) belong in 'd'.

edit2: actually, looking at it it's not that simple as glibc-2 contains some runtime/support executables that aren't in the other packages, so it couldn't just be dropped in 'd'.
Still like the idea of stripping out the headers into their own package and sticking that in 'd' mind you.

gnashley · 11-17-2013, 10:35 AM

On my system, I package glibc like this:
1. glibc - runtime only ~68MB
2. glibc-devel - headers, static-libs ~50MB
3. glibc-zone-info - timezone database ~63MB
4. glibc-i18n - the common parts of i18n support ~60MB
5. glibc-locale-* -250+ individual packages of each locale ~ 300K - 1500K each

The glibc-i18n common parts could be made smaller if the gconv libs and charmaps were split into the appropriate locale packages, or simply into another couple-a-hunderd tiny packages... Same for the timezone database... Of course, such a scheme is conceived for an installer which would help the user choose a locale, etc., and then only install the appropriate packages. It is nice, though to have i18n support with only for what is needed and for 60-65MB space used. I don't worry about disk-use much, but some people do, so making it possible in 60-65MB is nice.

I do similar packaging of kernel modules and firmware where many small packages are created, rather than throw them all together. It was fun writing the rotuines and I love watching while all those cute little packages are born...LOL

GazL · 11-17-2013, 10:55 AM

I like your approach gnashley. Of course, it's not just an issue of diskspace. that 100MB+ of duplicated stuff (though granted it compresses amazingly well) in the glibc-2 package multiplied by everyone who downloaded it probably adds up to quite a significant amount of network traffic.

Didier Spaier · 11-17-2013, 11:30 AM

I don't like the idea of having hundreds of packages for gconv at all, IMO the distribution should be fully localized or not at all upon user's choice, not partially. I don't like the idea of splitting glibc between -runtime and -devel either. Two of the many things I appreciate in Slackware are:

Relatively small number of packages to manage.
All included in each package (devel + runtime).

GazL · 11-17-2013, 12:34 PM

Quote:

Originally Posted by Didier Spaier

I don't like the idea of splitting glibc between -runtime and -devel either.

Hang on a minute!.. the reason you gave against my suggestion to just move glibc-2 to the 'a' set and get rid of the other packages entirely was that you didn't want the development headers installed, and now you're saying that you don't like a runtime/devel package split! ;P

Except of course, that is exactly what we already have anyway: glibc-solibs + zoneinfo + i18n = runtime; glibc-2 = devel(+ a bit of runtime not in the other packages). The only difference is that the glibc-2 package also duplicates what's in the other 3.

However, I do agree with you that the one package per locale, wouldn't really suit Slackware.

bormant · 11-18-2013, 09:45 AM

pros:
- no

contras:
- it is not needed in every system (main point of a set)
- it is really big

ReaperX7 · 11-18-2013, 08:27 PM

*sarcasm* Why not just roll all of glibc into one convenient package? glib-2.18_complete.x86_64.txz? This way nobody will know what to complain about? No fuss, no muss.

gnashley · 11-19-2013, 12:32 AM

Yeah, that would be consistent with the general scheme. Of course, then we'd need to do the same with a couple of other packages also.

GazL · 11-19-2013, 03:56 AM

Quote:

Originally Posted by ReaperX7

*sarcasm* Why not just roll all of glibc into one convenient package? glib-2.18_complete.x86_64.txz? This way nobody will know what to complain about? No fuss, no muss.

Before getting all *sarcastic* you should check into things a little more.

Code:

gazl@ws1:/tmp/glibc$ sed -e '0,/^FILE LIST:/d' /var/log/packages/glibc-2.17-x86_64-7  | sort > glibc_list
gazl@ws1:/tmp/glibc$ sed -e '0,/^FILE LIST:/d' /var/log/packages/glibc-solibs-2.17-x86_64-7  | sort > solibs_list
gazl@ws1:/tmp/glibc$ sed -e '0,/^FILE LIST:/d' /var/log/packages/glibc-zoneinfo-2013d-noarch-7  | sort > zone_list
gazl@ws1:/tmp/glibc$ sed -e '0,/^FILE LIST:/d' /var/log/packages/glibc-i18n-2.17-x86_64-7  | sort > i18n_list
gazl@ws1:/tmp/glibc$ comm -13 glibc_list i18n_list    # files unique to i18n
gazl@ws1:/tmp/glibc$ comm -13 glibc_list solibs_list  # files unique to solibs
gazl@ws1:/tmp/glibc$ comm -13 glibc_list zone_list    # files unique to zoneinfo
gazl@ws1:/tmp/glibc$

The glibc-2.17 package already is "one complete package". The other 3 packages duplicate subsets of the main package.