On 03.09.2011 17:41, Olivier Blin wrote:
> Thierry Vignaud writes:
>
>> On 2 September 2011 14:06, Michael Scherer wrote:
>>> It would help would be by having smaller hdlists, but I am not sure it
>>> would really help mirror so much. ( ie, I would not say "lots of space"
>>> even if that still
Le lundi 05 septembre 2011 à 11:25 +0200, Thierry Vignaud a écrit :
> On 3 September 2011 16:41, Olivier Blin wrote:
> >>> It would help would be by having smaller hdlists, but I am not sure it
> >>> would really help mirror so much. ( ie, I would not say "lots of space"
> >>> even if that still a
On 3 September 2011 16:41, Olivier Blin wrote:
>>> It would help would be by having smaller hdlists, but I am not sure it
>>> would really help mirror so much. ( ie, I would not say "lots of space"
>>> even if that still a saving )
>>
>> Actualy hdlist are pretty much unused these days.
>
> It wou
On 3 September 2011 18:52, Liam R E Quin wrote:
>> xml-info is used for the data not found in synthesis.
>
> At one point I started to look at using dbxml to read these, which could
> make rpmdrake much faster... it uses the bsd db package to keep an index
> of XML documents so you can search with
On Sat, 2011-09-03 at 11:06 +0300, Anssi Hannula wrote:
>
> xml-info is used for the data not found in synthesis.
At one point I started to look at using dbxml to read these, which could
make rpmdrake much faster... it uses the bsd db package to keep an index
of XML documents so you can search w
Thierry Vignaud writes:
> On 2 September 2011 14:06, Michael Scherer wrote:
>> It would help would be by having smaller hdlists, but I am not sure it
>> would really help mirror so much. ( ie, I would not say "lots of space"
>> even if that still a saving )
>
> Actualy hdlist are pretty much unu
On 02.09.2011 21:15, Maarten Vanraes wrote:
> Op vrijdag 02 september 2011 16:50:00 schreef Thierry Vignaud:
>> On 2 September 2011 14:06, Michael Scherer wrote:
>>> It would help would be by having smaller hdlists, but I am not sure it
>>> would really help mirror so much. ( ie, I would not say "
Am 03.09.2011 09:22, schrieb Maarten Vanraes:
Op zaterdag 03 september 2011 01:50:08 schreef Florian Hubold:
Am 02.09.2011 20:15, schrieb Maarten Vanraes:
Op vrijdag 02 september 2011 16:50:00 schreef Thierry Vignaud:
On 2 September 2011 14:06, Michael Scherer wrote:
It would help would be
Op zaterdag 03 september 2011 01:50:08 schreef Florian Hubold:
> Am 02.09.2011 20:15, schrieb Maarten Vanraes:
> > Op vrijdag 02 september 2011 16:50:00 schreef Thierry Vignaud:
> >> On 2 September 2011 14:06, Michael Scherer wrote:
> >>> It would help would be by having smaller hdlists, but I am
2011/9/2 Thierry Vignaud :
> On 2 September 2011 14:06, Michael Scherer wrote:
>> It would help would be by having smaller hdlists, but I am not sure it
>> would really help mirror so much. ( ie, I would not say "lots of space"
>> even if that still a saving )
>
> Actualy hdlist are pretty much un
Am 02.09.2011 20:15, schrieb Maarten Vanraes:
Op vrijdag 02 september 2011 16:50:00 schreef Thierry Vignaud:
On 2 September 2011 14:06, Michael Scherer wrote:
It would help would be by having smaller hdlists, but I am not sure it
would really help mirror so much. ( ie, I would not say "lots of
Op vrijdag 02 september 2011 16:50:00 schreef Thierry Vignaud:
> On 2 September 2011 14:06, Michael Scherer wrote:
> > It would help would be by having smaller hdlists, but I am not sure it
> > would really help mirror so much. ( ie, I would not say "lots of space"
> > even if that still a saving
On 2 September 2011 14:06, Michael Scherer wrote:
> It would help would be by having smaller hdlists, but I am not sure it
> would really help mirror so much. ( ie, I would not say "lots of space"
> even if that still a saving )
Actualy hdlist are pretty much unused these days.
urpmi (and thus th
FYI, I'm rsync'ing distrib-coffee with -lH flags, and watching
lilypond-doc download in full to each of the tree directories. Either
distrib isn't rsync'ing correctly (unlikely), or lilypond-doc isn't
packaged as a link ?
Le vendredi 02 septembre 2011 à 11:38 +0800, Funda Wang a écrit :
> 2011/9/2 Thomas Spuhler :
> > When upgrading lilypond I noticed that someone else mad the doc package
> > noarch
> > to "make the huge doc subpackage be noarch"
> >
> > 1. What is the advantage of this? We have noarch packages in
On 09/01/2011 11:38 PM, Funda Wang wrote:
We may split noarch packages into a new directory in the future, like
what opensuse is doing. That will save a lot of space for mirrors.
Whoever finally decided this, your children and your children's
children will rise up and call you blessed :-)
Le jeudi 1 septembre 2011 23:57:50, Thomas Spuhler a écrit :
> When upgrading lilypond I noticed that someone else mad the doc package
> noarch to "make the huge doc subpackage be noarch"
>
> 1. What is the advantage of this? We have noarch packages in i586 and
> x86_64 anyway
>
> 2. The result w
02.09.2011 10:15, Pascal Terjan kirjutas:
Yes there is still a bug in the build system, packages switching
between arch/noarch are not deleted
Is there bug about this issue? Who should fix it?
--
Sander
On Fri, Sep 2, 2011 at 03:57, Thomas Spuhler wrote:
> When upgrading lilypond I noticed that someone else mad the doc package noarch
> to "make the huge doc subpackage be noarch"
>
> 1. What is the advantage of this? We have noarch packages in i586 and x86_64
> anyway
They are hardlinks
> 2. The
Op vrijdag 02 september 2011 05:38:01 schreef Funda Wang:
> 2011/9/2 Thomas Spuhler :
> > When upgrading lilypond I noticed that someone else mad the doc package
> > noarch to "make the huge doc subpackage be noarch"
> >
> > 1. What is the advantage of this? We have noarch packages in i586 and
> >
2011/9/2 Thomas Spuhler :
> When upgrading lilypond I noticed that someone else mad the doc package noarch
> to "make the huge doc subpackage be noarch"
>
> 1. What is the advantage of this? We have noarch packages in i586 and x86_64
> anyway
We may split noarch packages into a new directory in the
When upgrading lilypond I noticed that someone else mad the doc package noarch
to "make the huge doc subpackage be noarch"
1. What is the advantage of this? We have noarch packages in i586 and x86_64
anyway
2. The result wasn't as intended, we now have the arch + noarch package in the
repos
22 matches
Mail list logo