[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: #38544: Gettext solution (Was: Re: gettext packages)

> > > In which case, let's aim to split the gettext package ;)
> > 
> > Well, you are the only one to insist so much in splitting the gettext
> > package. The reason you give me for this is that there are some stuff
> > which is normally not needed by the average user. I agree with that, but
> > IMHO, this is not a good reason for the split.
> > 
> > The same could be said for much larger packages than gettext.
> > 
> > Example: libc6-dev contains both the include files and the static
> > libraries. I guess that the include files are used by almost everybody
> > who has this package installed, while I could not say the same for the
> > static libraries.
> > 
> > Does this mean that libc6-dev has to be splitted also? (Please look at the
> > installed size of libc6-dev, and compare it with the installed size of
> > gettext).
> It's not such a stupid suggestion, perhaps.  But what does one package
> which might need to be broken have to do with another?

I has to do a lot: If we split gettext because it contains things which
are useful for different kind of people (users and developers), and we
do this based on the size of the package, then we should do the same for
every package having the same size to be consistent. However, we do not
split packages for the sake of splitting. It has to be a real gain.

Why don't you report "this package should be splitted because it is
too large and contains things which are not normally useful" as a bug
against libc6-dev?

> Anyway, I might pursue my intent to find a clean way to split the
> gettext package when I have some time.

Even if you find a "clean" way to split it, I think a good reason to
split it is still needed. Just because you think it must be split
does not make it a bug. It would be more productive to clearly state
the reasons why gettext "must" to be split while libc6-dev has not
before looking the way to split it.


 "c9675a733aeb21b7592bfd486d2713ab" (a truly random sig)

Reply to: