Re: Split translations to noarch packages?

[David Sommerseth]

> On 2 May 2017 at 11:14, David Sommerseth  wrote:
>> Show us a dist-git repos we can clone and run 'fedpkg mockbuild' and see
>> how this works for _Fedora_.
>>
>> How things are done in various other distributions doesn't mean it can
>> be re-used directly in Fedora.  And that tweaking is something we need
>> to have sorted out long before we can even consider doing something
>> similar in Fedora.  Without that we have no idea how to adopt this to a
>> full scale on all packages and how much work it will be.
> 
> Nice try 
> Seems you are posting from one of the email addresses blocked by
> fedora devel because there is no any traces of this email on
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2017/5/.

Wrong.



> I'm adding you to my spam filter so please do not bother reply to my
> public emails next time.

Just thought the list should beware of this attitude.

Oh and by the way, kloczek, thank you very much!  Now at least I know
you are not that serious about contributing to Fedora.  Which, by the
way, is quite confirmed here:


And I'm not going to spend more energy on this mail thread any more.


-- 
kind regards,

David Sommerseth



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[David Sommerseth]

On 02/05/17 08:18, Tomasz Kłoczko wrote:
> On 1 May 2017 at 14:42, Matthew Miller  wrote:
>> Tomasz, as I'm sure you know, our entire OS-creation infrastructure is
>> built around RPM. Suggesting we switch to another system is an ENORMOUS
> 
> Seems you did not read what I wrote careful.
> *I'm not suggesting switching to IPS.*
> I've pointed on IPS as software with tested and implemented some ideas
> about PM which can be *imported* to the RPM.
> 
> Please read one more time whole thread.

No.  Matthew understood me 100% correct.

Show us a dist-git repos we can clone and run 'fedpkg mockbuild' and see
how this works for _Fedora_.

How things are done in various other distributions doesn't mean it can
be re-used directly in Fedora.  And that tweaking is something we need
to have sorted out long before we can even consider doing something
similar in Fedora.  Without that we have no idea how to adopt this to a
full scale on all packages and how much work it will be.

The bottom line is:  Show us a proof-of-concept which can be deployed
and tested directly in Fedora.  And the POC *MUST* work in a Fedora
environment out-of-the-box you provide.


-- 
kind regards,

David Sommerseth



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 1 May 2017 at 14:42, Matthew Miller  wrote:
> Tomasz, as I'm sure you know, our entire OS-creation infrastructure is
> built around RPM. Suggesting we switch to another system is an ENORMOUS

Seems you did not read what I wrote careful.
*I'm not suggesting switching to IPS.*
I've pointed on IPS as software with tested and implemented some ideas
about PM which can be *imported* to the RPM.

Please read one more time whole thread.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Matthew Miller]

On Mon, May 01, 2017 at 08:55:13AM +0200, Tomasz Kłoczko wrote:
> On 30 April 2017 at 15:33, David Sommerseth  wrote:
> > Point us at some patches, git repos, .spec files, *whatever* which uses
> > your approach so we can see and get experience on how to resolve it.
> David I've already send few times URL to IPS source repo :)

Tomasz, as I'm sure you know, our entire OS-creation infrastructure is
built around RPM. Suggesting we switch to another system is an ENORMOUS
undertaking. You've already pointed us at it. *Repeatedly* pointing us
at the upstream is not helpful. Point us to your proof-of-concept
dist-git and build system and a plan to get from what we've got
(including a smooth upgrade path for all existing Fedora users) to
there. 

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 30 April 2017 at 15:33, David Sommerseth  wrote:
> Point us at some patches, git repos, .spec files, *whatever* which uses
> your approach so we can see and get experience on how to resolve it.

David I've already send few times URL to IPS source repo :)
Here it is one more time https://java.net/projects/ips/
All Solaris admins uses IPS. If you want try it just download it and install
http://www.oracle.com/technetwork/server-storage/solaris11/downloads/install-2245079.html
and documentation:
http://docs.oracle.com/cd/E53394_01/html/E54820/index.html
http://docs.oracle.com/cd/E53394_01/

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[David Sommerseth]

On 29/04/17 20:31, Tomasz Kłoczko wrote:
> 
>> As the saying goes: Talk is cheap!
> And this is what exactly I'm doing ..

And it is incredibly tiring with all your words.  Lets try another
idiom:  Don't talk the walk; walk the walk

Point us at some patches, git repos, .spec files, *whatever* which uses
your approach so we can see and get experience on how to resolve it.

If you're not coming up with anything concrete by now, you'll just be
ignored and mail threads of such types just gets silently ignored by the
mailing list recipients.


-- 
kind regards,

David Sommerseth



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 29 April 2017 at 22:30, Reindl Harald  wrote:
> given that i run Fedora fpr a decade on everyting from production servers to
> routers and desktops and reading all of your posts of the last week - well,
> i have no idea what your problem is

Looks like we have completely different jobs .. just accept this.
However this aspect has nothing do with this topic.
I can tell you only that there are plenty of examples where Solaris
even with paid support is cheaper than Linux without support because
in case of Linux to provide the same throughput needs to be used much
more powerful and by this expensive hardware. Many workloads cannot be
horizontally scaled so scaling service with hardware is only solution.
Bigger hardware means not only bigger initial costs but higher costs
of powering and cooling. In case of calculating costs of running
routers or desktops on scale few units I don't think that anyone is
thinking about those costs.
Does it mean that Solaris should be used everywhere? Of course not!!!
It would be idiotic.

But again: this thread is not about me or which OS is better in exact
context but about some exact technical aspects related to PM
technologies. This topic is quite static/parallel/fixed/the same as it
comes to management of some set of files used by running processes and
operating system. As some problems on exactly this area have been
already successfully solved on top of the Solaris there is no reason
to be ashamed telling again "we can do better!".

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 29 April 2017 at 19:14, Reindl Harald  wrote:
> but you are coming in several threads and tell everybody that Fedora has to
> be built completly different while the logical answer would be: well, if
> everything in Fedora is not the way you like it then Fedora probably just
> isn't for you?

Is it really so hard to guess that Linux and Solaris have own niches
on OS market and I'm kind of those guys which needs both OSes?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 29 April 2017 at 18:29, Neal Gompa  wrote:
> There's plenty of stuff going on in rpm.org upstream. You can look for
> yourself: https://github.com/rpm-software-management/rpm

Seems none is going to provide %doc and %lang() generalisation to
allow mark more than current 5 classes of the files within packages
like normal/regular file, %doc, %lang, %config and %ghost (%ghost is
practically %config with some exact %verify rules).
None is going towards provide IPS mediator functionality as well.

> I've even personally contributed to it. If you feel there is missing
> functionality, feel free to contribute and improve it. The upstream is
> very active, with contributions from individuals from Red Hat/Fedora,
> Mageia, SUSE/openSUSE, and even from BSD and Mac users!

I cannot find some polite words when I'm trying to describe what I'm
thinking when I'm looking on OpenSuse spec files .. but this is only
my private opinion. However from the begging SuSE guys had always
problems with understanding RPM as the technology (they've been using
it for quite long time as dumb Slackware tgz PM replacement without
significant changes on specs layer).
I would not expect any significant help from other rpm based distros
communities. Bottleneck is related to lack of people with enough
deep/long PM exp.

> As the saying goes: Talk is cheap!

And this is what exactly I'm doing ..
Problem is that most of the Linux folks have kind of natural Solaris
"allergy' thinking about it as legacy or dead OS.
Yep guys .. you are all wrong :-P
Solaris was, is and will be because Linux cannot bring to the desks of
the many engineers technologies which are available on Solaris OOTB ..
ONLY.
Truth is that on *many* areas Solaris still is more than decade ahead
of Linux and all this progress happen after Solaris 10 (so don't tell
me about your exp using Sol < 10 :) )
Just one example of last catch which is still in kind of embryonic
stage on Linux:
https://www.theregister.co.uk/2016/11/01/linux_in_2016_catches_up_to_solaris_from_2004/

Solaris userland changes are almost the same frequent as Fedora
(https://java.net/projects/solaris-userland/sources/gate/history?)
It is plenty of thing which could be adapted on Linux from Solaris.
What I'm trying to do now is more or less prevent reinvention all
those things second time :)

> IPS may have some awesome capabilities, so why not add them to RPM? No
> one has ever said we can't add best of breed features to RPM.

This is not about awesomeness. Some features are *needed*. Full stop.
Without those features more and more people will be bouncing own head
over bigger and bigger packages fragmentation with growing web of
dependencies and simple wasting time and not doing more important
things.

Really try to have look closer on IPS
https://java.net/projects/ips/sources/pkg-gate/show/
If you will look closer you may see that size of the python code in
which IPS is written is few times smaller with all additional python
modules compare to whole RPM code (source or binary).
Its is so simple because it bases on things which are still
unimaginable in LinuxWorld(tm) like doing upgrade on separated clones
of all affected FS not optionally like in ostree but unconditionally
(ZFS on Solaris is now only available FS which is supported to install
distro resources). Other set of features is related to 100% fixed set
of actions (more or less analogues of %filetrigger* in rpm). For many
RPM developer and packagers it will be total surprise that it was
possible to build fully functional packaging layer *without*
possibility to add even single customisation of the scriptlets fired
during pre/post install/uninstall!!!

Despite exactly those differences which affects semantics of
install/upgrade/remove/roll back IPS code provides as well all
necessary code of the services with package repository server, proxy,
maintenance tools. All with encryption/authentication etc.
Effectively IPS repo server it is set of resources served over
http/https using apache + few small bits in apache settings .. no
rocket science.
As IPS started from much wider set of problems which even now not
bothers typical Linux packager they (Sun developers) been able to make
few significant code layer generalisations/simplifications.

Parts which could be used on %doc/%lang generalisation (like IPS
facets), and variants management (mediators) and few other gems like
consolidations should be quite easy to extract from IPS and adapt on
top RPM. However mediators will require to change paradigm of the
package as archive to something which exist as the object in
repository (IPS allows export from repo package as archive but they
are used only on transferring resources between repos). With this step
already done switching to the space in which packages provides
multiarch resources sharing as much as it is only possible will be
formality.

IMO first step on this path could be stop using rpm and switch to use
dnf only (few weeks ago 

Re: Split translations to noarch packages?

[Neal Gompa]

On Sat, Apr 29, 2017 at 12:13 PM, Tomasz Kłoczko
 wrote:
> On 28 April 2017 at 21:32, Matthew Miller  wrote:
>> You do keep saying that it's easy. What I'm saying is that it's easy to
>> say things are easy, but... from experience, usually they are not. If
>> it *is* that easy, why not make a proof of concept? In any case, taking
>> them to the RPM project upstream is probably more fruitful than what
>> amounts to effectively nagging people who are attempting to make
>> improvements to _use_ within the existing functionality of the
>> software.
>
> You see it is only one big hole in you logic .. IPS exist!!!
> As long as you still going to refuse that IPS existence I must agree
> with you that it is really hard .. however I'm not going to share your
> pain because I'm using it on daily bases.
> Just control question: did you ever try *one time* to have look on IPS
> in meantime?
> If not this conversation does not make any sense because it is like
> trying to explain you taste of some dish you never been eating and
> probably never going to try.
>
> FYI: no one working on RPM is interested extending its functionality
>

There's plenty of stuff going on in rpm.org upstream. You can look for
yourself: https://github.com/rpm-software-management/rpm

I've even personally contributed to it. If you feel there is missing
functionality, feel free to contribute and improve it. The upstream is
very active, with contributions from individuals from Red Hat/Fedora,
Mageia, SUSE/openSUSE, and even from BSD and Mac users!

As the saying goes: Talk is cheap!

IPS may have some awesome capabilities, so why not add them to RPM? No
one has ever said we can't add best of breed features to RPM.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 28 April 2017 at 21:32, Matthew Miller  wrote:
> You do keep saying that it's easy. What I'm saying is that it's easy to
> say things are easy, but... from experience, usually they are not. If
> it *is* that easy, why not make a proof of concept? In any case, taking
> them to the RPM project upstream is probably more fruitful than what
> amounts to effectively nagging people who are attempting to make
> improvements to _use_ within the existing functionality of the
> software.

You see it is only one big hole in you logic .. IPS exist!!!
As long as you still going to refuse that IPS existence I must agree
with you that it is really hard .. however I'm not going to share your
pain because I'm using it on daily bases.
Just control question: did you ever try *one time* to have look on IPS
in meantime?
If not this conversation does not make any sense because it is like
trying to explain you taste of some dish you never been eating and
probably never going to try.

FYI: no one working on RPM is interested extending its functionality
(try to have look on what they are working on rpm 5.x on
http://rpm5.org/). In other words you may expect that Project Modules
with its new needs will have NULL support from RPM developers. Ergo:
without changes to import some IPS functionalities like mediators
which are able to check dependencies on switching variants this
project is already sentenced to FAIL. Developers working on this
project don't know about this or still refuses some basic facts and it
may take them even few years until they will agree that without deeper
changes in PM layer it will be not possible to reach goals of this
project.

Just my personal opinion: because IMO adding to RPM functionalities
will require at least 2-3 full time developers for +1 year and it will
be not possible to rewrite it easily (RPM have  over
complicated code). IMO more likely will be that within next few years
some Linux folks will take IPS as it is and will start packaging Linux
stuff using this PM software. It will be not a first time in Linux
history when Linux will be borrowing something from Solaris.
What you are guys trying to do with separating more and more noarch
subpackages is moving whole PM technology to pre-RPM era (+~22 years).
Really .. good luck with that. More packages -> more dependencies ->
higher probability that something will fail within resolving those
dependencies.
As long as even few years ago disk space was kind of issue today it is
nothing more than minor issue (even on small embedded systems it will
be less and less problem).
All those noarch separation will make more and more difficult use
Linux software provided by Fedora. Just one example: try to press F1
on any GNOME application and quite possible that you will see nice
small dialog box that help is not available. Only small percentage of
the people will start scratching own head trying to ask "why?" And
maybe few will find that it is because someone decided to separate
help files from *all* GNOME desktop application. Long term result:
less and less people will care about those help pages its quality or
translations to other languages ..
Yes you can start adding missing here dependencies but easier would be
just fix those issues by merge these resources because current
separations adds only complexity in spec files.
After such merge if someone hates to have installed any documentation
it will be very good solution by just add one line in /etc/rpm/rpmrc
and reinstall all packages by "rpm -qa | xargs dnf reinstall -y" (it
will take 20min to maybe 2-3h depends on network bandwidth and CPU
speed but recipe to do this is b*dy easy).
Cases when someone is using Linux with 32/64 bits binaries already is
decreasing. Investing time in more separation is already lost effort.

You may ignore me or name me as an idiot/fool (as some other people in
this thread not able to add any new argument) but I'm only messenger
..

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Milan Crha]

On Fri, 2017-04-28 at 21:09 +0200, Tomasz Kłoczko wrote:
> Can you tell us something about those priorities

Hi,
I've been generally speaking. Your "priority" is obviously IPS. Mine
not. Read the very first mail in this thread, to see my priorities and
why I started it.

> or maybe point to some URL where those priorities are listed?

I do not have any.

> I'm not like you RedHat employee so I have no idea about what you are
> talking about.

I see. I'm not talking for Red Hat, I'm talking for myself.

> Did you ever try to use IPS?

No.

> Did you saw its source code or how it works?

Neither this.

I'm just an average packager. I thought I'll ask wider audience about
an idea for something small and simple, nothing like changing packaging
system, need a learn new tool or whatever, just something simple which
can have interesting impact, but I didn't think I'll be punished for
it, by you, this way. Again, I speak for myself.

Anyway, this thread is over for me. Thank you for a valuable input.

Have a nice weekend,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Matthew Miller]

On Fri, Apr 28, 2017 at 09:17:19PM +0200, Tomasz Kłoczko wrote:
> I've already tried at least two times pointing not on something which
> is in development stage but is working and is used on enterprise
> systems for many years and is fully Open Source.
> What I've already know quite well is that some Linux believers suffers
> on something which is NIH syndrome and it bothers me because it would
> be good at least this time learn something from fully working tools
> like IPS.
> I'm not trying to convince anyone to switch from RPM to IPS. I'm only
> trying to tell that as IPS is fully OSS it can be used as stash of
> ideas which can be easily adapted on top of current RPM.

You do keep saying that it's easy. What I'm saying is that it's easy to
say things are easy, but... from experience, usually they are not. If
it *is* that easy, why not make a proof of concept? In any case, taking
them to the RPM project upstream is probably more fruitful than what
amounts to effectively nagging people who are attempting to make
improvements to _use_ within the existing functionality of the
software.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 28 April 2017 at 14:58, Matthew Miller  wrote:
> Again, please try "mode=constructive" for best results.

I've already tried at least two times pointing not on something which
is in development stage but is working and is used on enterprise
systems for many years and is fully Open Source.
What I've already know quite well is that some Linux believers suffers
on something which is NIH syndrome and it bothers me because it would
be good at least this time learn something from fully working tools
like IPS.
I'm not trying to convince anyone to switch from RPM to IPS. I'm only
trying to tell that as IPS is fully OSS it can be used as stash of
ideas which can be easily adapted on top of current RPM.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On Fri, 28 Apr 2017 at 09:19, Milan Crha  wrote:

> Different
> people has different point of view, different opinions, different
> priorities.
>

Can you tell us something about those priorities or maybe point to some URL
where those priorities are listed?
I'm not like you RedHat employee so I have no idea about what you are
talking about.
On what bases your different opinion and what exactly is this opinion?
Did you ever try to use IPS? Did you saw its source code or how it works?

kloczek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Matthew Miller]

On Thu, Apr 27, 2017 at 10:29:19PM +0200, Tomasz Kłoczko wrote:
> So far *only* argument was that his split may save ~1GB on ftp server.
> [mode=sarcastic]
> If Fedora Foundation is in so big financial troubles I can donate 1GB
> SD card out of my pocket (probably 2-3 pounds with delivery to US).
> Just please give me address where this card needs to be delivered.
> [/mode]

Again, please try "mode=constructive" for best results.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Milan Crha]

On Tue, 2017-04-25 at 13:10 +0200, Tomasz Kłoczko wrote:
> So you guys want to say that you never heard that in %files is
> possible to add %lang() tokens

Hi,
no, I never heard about that, though I'm not a good packager, thus it
doesn't mean much. Though it can be because %lang() is way too
complicated with compare of "Recommended method of handling i18n
files" [1] as referenced from [2], which is significantly easier for
packagers like me and which is used in evolution packages for years.
Bye,
Milan

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files
[2] https://fedoraproject.org/wiki/How_to_create_an_RPM_package
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Milan Crha]

Hi,

On Thu, 2017-04-27 at 19:25 +, Tomasz Kłoczko wrote:
> No generall agreement for such changes, ignoring already mentioned
> arguments.
> Seems only just because "we can".

Nope, you are wrong. I gave clear explanation why I did so. Sure, some
people, like you, might not like it. Okay, that happens. Different
people has different point of view, different opinions, different
priorities.

In any way, the way you speak in this thread makes me just ignore you
specifically, because you are not adding anything constructive. I'm
sorry. That's just my opinion.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 27 April 2017 at 22:42, Björn 'besser82' Esser <
besse...@fedoraproject.org> wrote:
> Fedora currently has about 19k packages in each maintained release /
branch,
> thats a total of about 76k packages.  If such a little change saves about
> 100KB of storage in average for every single package, it's a total saving
of
> about 7.25 GB.  This saves about 7.25 GB for syncing of each mirror; for
242
> active mirrors that's a total of 1.71 TB of transmitted data…

bash provides in own doc subpackages tripled the same documentation (info
and two copies of the pdf version the same doc in files under different
names).
Why no one cares abou this?

Try to think that if packages will exist only as the objects in repository
it will be not possible to save 1GB but much more by sharing on the repos
server side common parts between packages for different architectures.

Try to have look for example on mc package metadata in Solaris IPS
repository
http://pkg.oracle.com/solaris/release/manifest/0/file%2Fmc@4.8.17%2C5.12-5.12.0.0.0.115.0%3A20170111T171112Z
You can find in those metadata lines:

file 7080b660d77d5d260f95e269626f2900b36cba0e
chash=c2ef7983c385175c32f6ac6990175289529aa1ea elfarch=sparc elfbits=64
elfhash=0fd93599aef1c81668aad3063a2ddc2d8fa60fd6 group=bin mode=0555
owner=root path=usr/bin/mc pkg.csize=733172 pkg.size=2059216
variant.arch=sparc

and

file be26b559c366018c655c16d3dabf46ab61bcf962
chash=5e2285f84f85e71e63f763ea151ecabed9e342b3 elfarch=i386 elfbits=64
elfhash=c171f543984c3da03cf479dbc10d1ec3b0bf9aac group=bin mode=0555
owner=root path=usr/bin/mc pkg.csize=622533 pkg.size=1916544
variant.arch=i386

One package holds all architectures binaries sharing all other files.
Do you see now how much MORE on all packages servers is possible to save
disk space using this approach?

In IPS repository is not a problem keeping longer history of different
versions or the same package across many revisions/versions as most of the
files on repo server side will be shared between those multiple versions.
Do you see this now?

In Fedora for me most frequent problem is that as long as I'musing rawhide
sometimes I'm not doing regularly every day updates and when I'm finding
that some process is crashing I cannot download correct debuginfo packages
because it already has been deleted.
In publically available IPS repos like
http://pkg.oracle.com/solaris/release/en/index.shtml you ca find only few
major releases. However with support you can have access to all past every
~month SRUs packages revisions from all last few years and it does not need
tenths of terabytes of storage.
In Solaris each binary is served with way smaller deguginfo integrated into
regular binaries. Size of this additional data is so small that Solaris
developers decided to provide debuginfo in regular distro packages.
In Fedora debuginfo are sometimes 10x bigger than rest of the regular
package.

If you really care about size here are biggest deposits of things which
Linux can learn from his more mature cousins.
Solaris IPS was reply on RPM and growing demands of solving other problems
which Fedora barely stats to fight (try to have look on IPS mediators and
you will cee that they are solves ALL problems which Modules guys just
started thinking how to solve on top of unchanged RPM).
After IPS introduction about 9 years ago nothing happen on RPM area .. full
stagnation which now causes that some desperate package developers are
thinking about create even more subpackages because RPM cannot provide some
useful solutions.

Guys if you are thinking that splitting langpack subpackages may solve
something you are 100% right .. you are only thinking.


kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
-- 
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 27 April 2017 at 22:34, Reindl Harald  wrote:
>> So far *only* argument was that his split may save ~1GB on ftp server.
>> [mode=sarcastic]
>
> no

Gosh .. so seems like I've lost few emails in this thread!!!
Could you please forward on my prv email address this email with other
than this "1GB" arguments?

[..]
> sorry, but you are a fool

Hmm .. could you please tell me when we switched subject from
splitting langpacks to my person? (rhetorical question)

[..]
> [harry@srv-rhsoft:~]$ df
> FilesystemTypeSize  Used Avail Use% Mounted on
[..]
> /dev/md2  ext43.6T  2.3T  1.3T  64% /mnt/data

Ufff .. full relief that Fedora still have more than few GB free space.

So if lack of free disk space is not an issue I'll be patiently only
waiting on this lost email with full explanation why instead investing
in rpm development is less important than moving whole packaging to
pre %land() and %doc era (something like +17 years ago).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Björn 'besser82' Esser]

Am 27.04.2017 um 22:29 schrieb Tomasz Kłoczko:

On 27 April 2017 at 21:54, Reindl Harald  wrote:

Am 27.04.2017 um 21:50 schrieb Tomasz Kłoczko:

OK so what kind of problem solves those changes? Can I have look on some
bugzilla entry?

split packages where it *really* matters instead create thousands of small
rpm packages where the metadata and overhead is much larger than the few
bytes in the standard package?

So far *only* argument was that his split may save ~1GB on ftp server.


And lots of terabytes when syncing the mirrors…


[mode=sarcastic]
If Fedora Foundation is in so big financial troubles I can donate 1GB
SD card out of my pocket (probably 2-3 pounds with delivery to US).
Just please give me address where this card needs to be delivered.
[/mode]


It's not about the money, really…  This is a great step towards 
"Green-IT"…  Every bit of a transmission needs energy and it is a great 
idea to save energy, by just such a little change.


Fedora currently has about 19k packages in each maintained release / 
branch, thats a total of about 76k packages.  If such a little change 
saves about 100KB of storage in average for every single package, it's a 
total saving of about 7.25 GB.  This saves about 7.25 GB for syncing of 
each mirror; for 242 active mirrors that's a total of 1.71 TB of 
transmitted data…


Cheers,
  Björn
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 27 April 2017 at 21:54, Reindl Harald  wrote:
> Am 27.04.2017 um 21:50 schrieb Tomasz Kłoczko:
>>
>> OK so what kind of problem solves those changes? Can I have look on some
>> bugzilla entry?
>
> split packages where it *really* matters instead create thousands of small
> rpm packages where the metadata and overhead is much larger than the few
> bytes in the standard package?

So far *only* argument was that his split may save ~1GB on ftp server.
[mode=sarcastic]
If Fedora Foundation is in so big financial troubles I can donate 1GB
SD card out of my pocket (probably 2-3 pounds with delivery to US).
Just please give me address where this card needs to be delivered.
[/mode]

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Matthew Miller]

On Thu, Apr 27, 2017 at 07:50:40PM +, Tomasz Kłoczko wrote:
> OK so what kind of problem solves those changes? Can I have look on some
> bugzilla entry?

Talking to the maintainers of that package nicely is generally the best
approach. Or even better, *build* that better approach and *show*.
Telling people that we should switch to a theoretical solution that you
*say* would be quite easy is a lot different from actually _making_ it
easy for people.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

OK so what kind of problem solves those changes? Can I have look on some
bugzilla entry?

kloczek

On Thu, 27 Apr 2017 at 21:47, Matthew Miller 
wrote:

> On Thu, Apr 27, 2017 at 07:25:32PM +, Tomasz Kłoczko wrote:
> > Seems like splitting langpacks subpackages in all evolution packages few
> > minutes ago just started.
> > No generall agreement for such changes, ignoring already mentioned
> > arguments.
> > Seems only just because "we can".
>
> That's true. Within the existing guidelines and policies, we give our
> packagers a lot of latitude for solving the problems in the packages
> they maintain. If we decide we need a general policy for something, we
> can do that, but we don't have to nor do we always want to.
>
> > Guys if you are bored just please undress, sit down next to your clothes
> > and watch your cloths. This will be way more productive.
>
> Seriously, please. This is not constructive.
>
> > PS. Did anyone notice that Fedora in popularity ranking on
> distrowatch.com
> > dropped recently?
>
> That seems... decidedly unrelated. And, Distrowatch is a silly thing to
> use as a metric for _anything_. As it says itself, the rankings
> "correlate neither to usage nor to quality and should not be used to
> measure the market share of distributions."
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
-- 
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Matthew Miller]

On Thu, Apr 27, 2017 at 07:25:32PM +, Tomasz Kłoczko wrote:
> Seems like splitting langpacks subpackages in all evolution packages few
> minutes ago just started.
> No generall agreement for such changes, ignoring already mentioned
> arguments.
> Seems only just because "we can".

That's true. Within the existing guidelines and policies, we give our
packagers a lot of latitude for solving the problems in the packages
they maintain. If we decide we need a general policy for something, we
can do that, but we don't have to nor do we always want to.
 
> Guys if you are bored just please undress, sit down next to your clothes
> and watch your cloths. This will be way more productive.

Seriously, please. This is not constructive.

> PS. Did anyone notice that Fedora in popularity ranking on distrowatch.com
> dropped recently?

That seems... decidedly unrelated. And, Distrowatch is a silly thing to
use as a metric for _anything_. As it says itself, the rankings
"correlate neither to usage nor to quality and should not be used to
measure the market share of distributions."

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

Seems like splitting langpacks subpackages in all evolution packages few
minutes ago just started.
No generall agreement for such changes, ignoring already mentioned
arguments.
Seems only just because "we can".

Guys if you are bored just please undress, sit down next to your clothes
and watch your cloths. This will be way more productive.

kloczek
PS. Did anyone notice that Fedora in popularity ranking on distrowatch.com
dropped recently?


On Thu, 27 Apr 2017 at 20:07, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Thu, Apr 27, 2017 at 02:07:34PM +0200, Milan Crha wrote:
> > I did with evolution core packages what I thought is the best. I do not
> > use weak dependencies, I define a hard dependency between the langpacks
> > and the binary package, both ways, thus users get either both or none
> > of them. That makes the change backward compatible, while still helping
> > with disk usage on build servers and mirrors.
>
> There is a better way to preserve backwards compat:
> define Obsoletes: %{name} < [version] in both the main package and the
> langpacks packages. Then dnf will install both on upgrade, and users
> can still uninstall langpacks.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1260394 for some
> discussion.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
-- 
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 27, 2017 at 02:07:34PM +0200, Milan Crha wrote:
> I did with evolution core packages what I thought is the best. I do not
> use weak dependencies, I define a hard dependency between the langpacks
> and the binary package, both ways, thus users get either both or none
> of them. That makes the change backward compatible, while still helping
> with disk usage on build servers and mirrors.

There is a better way to preserve backwards compat:
define Obsoletes: %{name} < [version] in both the main package and the
langpacks packages. Then dnf will install both on upgrade, and users
can still uninstall langpacks.

See https://bugzilla.redhat.com/show_bug.cgi?id=1260394 for some discussion.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Milan Crha]

On Thu, 2017-04-27 at 13:31 +0200, David Tardon wrote:
> There is a reason that libreoffice puts l10n data into separate
> subpackages.

Hi,
yes, there is a very good reason for it and I'm not questioning that.
libreoffice was just an example of a package which does that already,
but also fails to do the right (or better "expected by me") thing, for
which you gave a bug link. Thanks for it.

As had been said in this thread, one approach doesn't work for all
packages. I made it my way for the core evolution packages this morning
for rawhide. There is only one langpacks subpackage. I looked also on
syncevolution, because I've been curious, and the split translations
package was around 90KB of size, thus it didn't make any sense to split
the translations and I left syncevolution unchanged. That makes me
think that there are these kinds of packages:
a) without any translation - no changes for these
b) with only a small translations - like syncevolution, split doesn't
   make sense
c) with semi-large translations - packages, where split translations by
   language is less useful or impractical, thus one package with all
   languages is preferred/used
d) with large translations - languages are that large that it's
   better to split the langpacks into per-language subpackages
e) with large translations and additions - like libreoffice,
   translations split by language as well, but libreoffice also adds
   more dependencies to these translation packages (as you said).

I did with evolution core packages what I thought is the best. I do not
use weak dependencies, I define a hard dependency between the langpacks
and the binary package, both ways, thus users get either both or none
of them. That makes the change backward compatible, while still helping
with disk usage on build servers and mirrors. One part of backward
compatibility in this case is also related to d),e) above, where, for
the way I made it, users can switch languages and they will have the UI
translated without a need to install additional package(s).

When starting this thread here, I did not intent to suggest any change
on the build servers to do things automatically, I was more interested
in ideas and opinions of other packagers. It would be nice to have
these things done transparently, with minimal lines in RPM .spec file,
but as there are a-b-c-d-e cases named above (and/or there can be found
even more), then it makes it impractical. If this thread will lead to
some "nice-to-have packaging guideline", then it would be welcome and
more than I expected from it.

> Btw, I'm not sure what do you mean by "divide langpacks by country". 

It's just a terminology. What I call "by country", other (more
educated) folks call "by language/region/variant". Simply
not-all-translations in one single subpackage.

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[David Tardon]

Hi,

On Mon, Apr 24, 2017 at 06:15:49PM +0200, Milan Crha wrote:
> On Mon, 2017-04-24 at 08:18 -0400, Stephen Gallagher wrote:
> > If we went this route, I'd love to see us attempt to solve this
> > generically for all packages if at all possible.
> 
> My main issue with libreoffice langpacks divided by country was that
> even I chose my mother language during installation of Fedora, that
> particular langpack wasn't installed, thus libreoffice was not
> localized to my mother language, though other parts, like GNOME Shell,
> were. This is few Fedora's back, on a machine which I keep updating,
> instead of installing from scratch, thus it's possible the behaviour
> changed meanwhile.

https://bugzilla.redhat.com/show_bug.cgi?id=1401096

> 
> I mean, maybe it doesn't make always sense to divide langpacks by
> country.

There is a reason that libreoffice puts l10n data into separate
subpackages. libreoffice currently builds with 69 languages. The size of
UI l10n data is 2-3 MB per language. In addition, about half of the
langpacks contain help. That's another 20+ MB per language. That makes
1.4 GB of installed size (194 MB even without help). Plus dependencies:
the langpacks pull in hunspell, mythes, autocorr and font packages for
given langugage.

Btw, I'm not sure what do you mean by "divide langpacks by country". The
langpacks are divided by language; only pt is further divided by region
(pt-PT and pt-BR) and zh by variant (zh-Hans and zh-Hant).

D.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 26 April 2017 at 17:41, Neal Gompa  wrote:
> The problem with this approach is that it's not possible for the user
> to get additional locale content without reinstalling after enabling
> another locale (by installing the associated system langpack package
> that controls this). Splitting them out into langpack subpackages
> guarantees that it's possible to do that.

No it is not a problem generally at all.
This has been solved in Solaris IPS 6-7 years ago.
As long as package in IPS does not exist in form of archive and it
exist only as object in repository operation like:

# pkg change-facet lang.fr=true

checks in repository which one files are marked by "facet
lang.fr=true" and adds those files to the already installed files
across all already installed packages. Because packages all packages
exists in repo as sets of files with some attributes pkg downloads
only those missing files (not whole packages).
IPS developers learned from RPM about %doc and %lang() nd they've
chose some generic markings over "facet" and they've changed it
generic technique. Truth is that in recent years RPM stagnated and
effectively is much simpler and at the same time much more advanced
than RPM.
Instead trying to find "workaround" RPM should follow he same path
which IPS proven that it may solve a lot more serious problems on
front of which are now Modules Fedora Project developers with provide
alternatives within packages management.

RPM with current paradigm of the packages will be not able to solve
those challenges. If RPM will be not extended to start operate on
packages existing only in repositories IMO more likely some Linux
folks will fork for example Fedora to build Linux distribution using
IPS instead RPM. It will be quite easy because using pkgbuild
(https://pkgbuild.sf.net/)is possible to build IPS packages using only
slightly adapted RPM spec files.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Neal Gompa]

On Tue, Apr 25, 2017 at 7:10 AM, Tomasz Kłoczko
 wrote:
> On 25 April 2017 at 01:16, Rafal Luzynski
>  wrote:
>>
>> But for small packages which have not so many translatable
>> messages producing dozens of small RPMs ~1 kilobyte each or even
>> less would doesn't sound like a good solution. So I suggest to
>> introduce this feature but not globally and obligatorily for
>> all packages.
>>
>> Additionally, I think that for some purposes installing all
>> languages for some specific applications would be useful so
>> I also suggest providing something like glibc-all-langpacks.
>
> So you guys want to say that you never heard that in %files is
> possible to add %lang() tokens and when you will put in
> /etc/rpm/rpmrc line:
>
> %_install_langs [,,[..]]
>
> or
>
> %_install_langs all
>
> you evey install new or upgrade existing package will cause that only
> resources marked in %files by exact %lang() tokens will be installed?
> ???
> And you never heard about this possibility to add %packages section
> name param like:
>
> %packages --instLangs [,,[..]]
>
> by which you initial installation using anaconda installed will be
> done only with installed files marked only exact languages tokens?
> Really?
> I'm really disappointed as I'm personally contributed more than 10
> years ago some parts in find-lang.sh script which is behind %find_lang
> macro which simplifies adding %lang() tokens to some well known
> classes of files which may be a part of some packages.
>
> Looks as well like some people never heard that in %files section is
> possible to add %doc tokens and by this possible to choose install
> system without installed documentation (and this is why this overkill
> with doc packages already happens). Installation with documentation
> exclusion is fully supported by rpm, dff and anaconda installer as
> well.

The problem with this approach is that it's not possible for the user
to get additional locale content without reinstalling after enabling
another locale (by installing the associated system langpack package
that controls this). Splitting them out into langpack subpackages
guarantees that it's possible to do that.

The filtering is useful for inconsequential ones, where it's just not
worth it to split, but otherwise, it's not.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Matthew Miller]

On Tue, Apr 25, 2017 at 01:16:44AM +0200, Rafal Luzynski wrote:
> But for small packages which have not so many translatable
> messages producing dozens of small RPMs ~1 kilobyte each or even
> less would doesn't sound like a good solution. So I suggest to
> introduce this feature but not globally and obligatorily for
> all packages.

I think we should look at this from a different angle. I think we
should split them out where the languages are large _or_ the packages
are likely to go in release artifacts where size is at a premium:
Atomic Host, Container Base Image, and the Live images. If it's only a
few K and isn't used in a size-important case, skip it.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Silvia Sanchez]

Hello all,
I agree with Rafal. I think that in the case of small or medium
packages this would be counterproductive.
Kind regards,Silvia


On Tue, 2017-04-25 at 01:16 +0200, Rafal Luzynski wrote:
> 24.04.2017 12:47 Milan Crha  wrote:
> > [...]
> > I know I can do this for packages I maintain, but I though it would
> > make sense to think of it globally. Maybe?
> > 
> > Bye,
> > Milan
> 
> If I may drop my 2¢… this sounds good to me for large packages,
> for example LibreOffice, glibc and KDE which do it already and
> Evolution as a good candidate to implement this change.
> 
> But for small packages which have not so many translatable
> messages producing dozens of small RPMs ~1 kilobyte each or even
> less would doesn't sound like a good solution. So I suggest to
> introduce this feature but not globally and obligatorily for
> all packages.
> 
> Additionally, I think that for some purposes installing all
> languages for some specific applications would be useful so
> I also suggest providing something like glibc-all-langpacks.
> 
> Regards,
> 
> Rafal
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 25 April 2017 at 01:16, Rafal Luzynski
 wrote:
>
> But for small packages which have not so many translatable
> messages producing dozens of small RPMs ~1 kilobyte each or even
> less would doesn't sound like a good solution. So I suggest to
> introduce this feature but not globally and obligatorily for
> all packages.
>
> Additionally, I think that for some purposes installing all
> languages for some specific applications would be useful so
> I also suggest providing something like glibc-all-langpacks.

So you guys want to say that you never heard that in %files is
possible to add %lang() tokens and when you will put in
/etc/rpm/rpmrc line:

%_install_langs [,,[..]]

or

%_install_langs all

you evey install new or upgrade existing package will cause that only
resources marked in %files by exact %lang() tokens will be installed?
???
And you never heard about this possibility to add %packages section
name param like:

%packages --instLangs [,,[..]]

by which you initial installation using anaconda installed will be
done only with installed files marked only exact languages tokens?
Really?
I'm really disappointed as I'm personally contributed more than 10
years ago some parts in find-lang.sh script which is behind %find_lang
macro which simplifies adding %lang() tokens to some well known
classes of files which may be a part of some packages.

Looks as well like some people never heard that in %files section is
possible to add %doc tokens and by this possible to choose install
system without installed documentation (and this is why this overkill
with doc packages already happens). Installation with documentation
exclusion is fully supported by rpm, dff and anaconda installer as
well.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Rafal Luzynski]

24.04.2017 12:47 Milan Crha  wrote:
> [...]
> I know I can do this for packages I maintain, but I though it would
> make sense to think of it globally. Maybe?
>
> Bye,
> Milan

If I may drop my 2¢… this sounds good to me for large packages,
for example LibreOffice, glibc and KDE which do it already and
Evolution as a good candidate to implement this change.

But for small packages which have not so many translatable
messages producing dozens of small RPMs ~1 kilobyte each or even
less would doesn't sound like a good solution. So I suggest to
introduce this feature but not globally and obligatorily for
all packages.

Additionally, I think that for some purposes installing all
languages for some specific applications would be useful so
I also suggest providing something like glibc-all-langpacks.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Tomasz Kłoczko]

On 24 April 2017 at 20:37, Stephen Gallagher  wrote:

> These days, I think we divide langpacks (at least at the distro/glibc
> level) by language rather than country.
>
> I have `langpacks-en` on my system, for example.
>

Yep .. "these days" glibc is one of the best anti examples about how to
write specs files.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Stephen Gallagher]

On 04/24/2017 12:15 PM, Milan Crha wrote:
> On Mon, 2017-04-24 at 08:18 -0400, Stephen Gallagher wrote:
>> If we went this route, I'd love to see us attempt to solve this
>> generically for all packages if at all possible.
>   Hi,
> right, having this done transparently for the packagers would be ideal.
> You only need to decide from which build/architecture you'll compose
> that noarch package. Evolution package used to remove unused translated
> strings in the past, during the build.
>
> My main issue with libreoffice langpacks divided by country was that
> even I chose my mother language during installation of Fedora, that
> particular langpack wasn't installed, thus libreoffice was not
> localized to my mother language, though other parts, like GNOME Shell,
> were. This is few Fedora's back, on a machine which I keep updating,
> instead of installing from scratch, thus it's possible the behaviour
> changed meanwhile.
>
> I mean, maybe it doesn't make always sense to divide langpacks by
> country.


These days, I think we divide langpacks (at least at the distro/glibc
level) by language rather than country.

I have `langpacks-en` on my system, for example.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Milan Crha]

On Mon, 2017-04-24 at 08:18 -0400, Stephen Gallagher wrote:
> If we went this route, I'd love to see us attempt to solve this
> generically for all packages if at all possible.

Hi,
right, having this done transparently for the packagers would be ideal.
You only need to decide from which build/architecture you'll compose
that noarch package. Evolution package used to remove unused translated
strings in the past, during the build.

My main issue with libreoffice langpacks divided by country was that
even I chose my mother language during installation of Fedora, that
particular langpack wasn't installed, thus libreoffice was not
localized to my mother language, though other parts, like GNOME Shell,
were. This is few Fedora's back, on a machine which I keep updating,
instead of installing from scratch, thus it's possible the behaviour
changed meanwhile.

I mean, maybe it doesn't make always sense to divide langpacks by
country.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Split translations to noarch packages?

[Stephen Gallagher]

On 04/24/2017 06:47 AM, Milan Crha wrote:
>   Hello,
> I've got an idea and I'd like to know an opinion of a wider audience.
>
> Would it make sense to split translations from binary packages to
> a noarch subpackage?
>
> For example libreoffice does that already, it even splits the languages
> by country, which may or may not be applicable to other (larger)
> packages as well.
>
> What this could help with is a save of disk space on the build servers
> and mirrors. There might not be any significant difference for users,
> due to the main package would require the "langs" subpackage [*]. One
> may even avoid multilib issues on translation files (happened in the
> past for Evolution due to it removing unused translation strings during
> the build, to save package size).
>
> To give an example, I tried this with Evolution package and the result
> is that the langs subpackage is ~6MB large, while the main package is
> ~4MB large. Count that the languages are stored for each architecture,
> and koji builds for 6 of them at the moment, then the change of split
> means saving 30MB on disk for each single build of Evolution. When
> searching koji for Evolution packages then there had been done more
> than 70 builds since the first build for Fedora 24 (which is built for
> 3 arches only), which means more than 1GB on disk (roughly, counting 3
> arches only). Multiply this by number of mirrors and so on.
>
> I know I can do this for packages I maintain, but I though it would
> make sense to think of it globally. Maybe?
>
>   Bye,
>   Milan
>
> [*] The only difference for users would be to not download languages
> again when installing two+ architectures in parallel, thus less data to
> download, thus only a benefit for them.


If we went this route, I'd love to see us attempt to solve this
generically for all packages if at all possible. Something like having
the rpmbuild step extract the *.po files automatically into their own
subpackages and set the appropriate `Supplements: langpack-`[1]
values for them. That way the next time we do a mass-rebuild, every
package in the distribution would take advantage of it automatically.


[1] https://fedoraproject.org/wiki/Packaging:Langpacks



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org