Hi,

The package djvulibre now conflicts and provides libdjvu, and libdjvu
disappeared from the repository.

However, judging by the files they provide and the PKGBUILD cached in
my abs directory, I don't think they are the same thing. djvulibre
does not provide the dynamic linked library as libdjvu does and thus
may break other application depending on libdjvu. For instance,
/usr/lib/evince/3/backends/libdjvudocument.so from evince package
links to /usr/lib/libdjvulibre.so.21, which would be removed if I
update the system to allow djvulibre to replace libdjvu.

What's happened to the libdjvu package? Why is it removed from
repository? Should I file a bug report?

Best Regards,

Am 21.10.2010 13:38, schrieb Auguste Pop:
> For instance,
> /usr/lib/evince/3/backends/libdjvudocument.so from evince package
> links to /usr/lib/libdjvulibre.so.21, which would be removed if I
> update the system to allow djvulibre to replace libdjvu.

This is false, the djvulibre package contains this library.

On 10/21/2010 02:38 PM, Auguste Pop wrote:

Hi,

The package djvulibre now conflicts and provides libdjvu, and libdjvu
disappeared from the repository.

However, judging by the files they provide and the PKGBUILD cached in
my abs directory, I don't think they are the same thing. djvulibre
does not provide the dynamic linked library as libdjvu does and thus
may break other application depending on libdjvu. For instance,
/usr/lib/evince/3/backends/libdjvudocument.so from evince package
links to /usr/lib/libdjvulibre.so.21, which would be removed if I
update the system to allow djvulibre to replace libdjvu.

What's happened to the libdjvu package? Why is it removed from
repository? Should I file a bug report?

Best Regards,


that is replacing libdjvu and nothing that you say above is true.

pacman -Ql djvulibre | grep libdjvulibre.so
djvulibre /usr/lib/libdjvulibre.so
djvulibre /usr/lib/libdjvulibre.so.21
djvulibre /usr/lib/libdjvulibre.so.21.2.0

this means that /usr/lib/evince/3/backends/libdjvudocument.so is not
broken because djvulibre provides the same soname


--
IonuÈ›

On 21/10/10 21:38, Auguste Pop wrote:

Hi,

The package djvulibre now conflicts and provides libdjvu, and libdjvu
disappeared from the repository.

However, judging by the files they provide and the PKGBUILD cached in
my abs directory, I don't think they are the same thing. djvulibre
does not provide the dynamic linked library as libdjvu does and thus
may break other application depending on libdjvu. For instance,
/usr/lib/evince/3/backends/libdjvudocument.so from evince package
links to /usr/lib/libdjvulibre.so.21, which would be removed if I
update the system to allow djvulibre to replace libdjvu.

What's happened to the libdjvu package? Why is it removed from
repository? Should I file a bug report?


The new package looks to contain that library to me...

[allan@gerolde ~]$ tar -tf
/srv/ftp/extra/os/i686/djvulibre-3.5.23-1-i686.pkg.tar.xz | grep usr/lib

usr/lib/
usr/lib/pkgconfig/
usr/lib/libdjvulibre.so.21.2.0
usr/lib/libdjvulibre.so
usr/lib/libdjvulibre.so.21
usr/lib/pkgconfig/ddjvuapi.pc

I noticed this by compiling the package myself... When I sent this
mail, the web page was not updated and I saw an old list of files that
did not contain the .so file. I should have tried it first rather than
relying on a presumably delayed response on the web site. Sorry for
the false alarm.

> Message: 6
> Date: Thu, 21 Oct 2010 13:43:43 +0200
> From: Thomas B?chler <thomas@archlinux.org>
> Subject: Re: [arch-general] What's happening about libdjvu?
> To: General Discussion about Arch Linux <arch-general@archlinux.org>
> Message-ID: <4CC0276F.9050906@archlinux.org>
> Content-Type: text/plain; charset="iso-8859-15"
>
> Am 21.10.2010 13:38, schrieb Auguste Pop:
>> For instance,
>> /usr/lib/evince/3/backends/libdjvudocument.so from evince package
>> links to /usr/lib/libdjvulibre.so.21, which would be removed if I
>> update the system to allow djvulibre to replace libdjvu.
>
> This is false, the djvulibre package contains this library.
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 262 bytes
> Desc: OpenPGP digital signature
> URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20101021/575a37a9/attachment-0001.bin>
>

Am 21.10.2010 15:56, schrieb Auguste Pop:
> I noticed this by compiling the package myself... When I sent this
> mail, the web page was not updated and I saw an old list of files that
> did not contain the .so file. I should have tried it first rather than
> relying on a presumably delayed response on the web site. Sorry for
> the false alarm.

The update of the file list in the web interface might be delayed
compared to the update of the package data itself.

Dan, what can we do here? Should a version mismatch between $repo.db and
$repo.files cause archweb to discard the file list, stating that "There
is currently no file list available for this package", or should archweb
print a warning "This is a file list from an older version of this
package and might differ from the current package". Is anything like
this already done in archweb? Should it?

Right now, the delay between updating the package info and the file list
can be (in the worst case) little over 24 hours. Given that our packages
update and change frequently, I think we should avoid confusion like in
Auguste's case.

Am 21.10.2010 15:56, schrieb Auguste Pop:
> I noticed this by compiling the package myself... When I sent this
> mail, the web page was not updated and I saw an old list of files that
> did not contain the .so file. I should have tried it first rather than
> relying on a presumably delayed response on the web site. Sorry for
> the false alarm.

The update of the file list in the web interface might be delayed
compared to the update of the package data itself.

Dan, what can we do here? Should a version mismatch between $repo.db and
$repo.files cause archweb to discard the file list, stating that "There
is currently no file list available for this package", or should archweb
print a warning "This is a file list from an older version of this
package and might differ from the current package". Is anything like
this already done in archweb? Should it?

Right now, the delay between updating the package info and the file list
can be (in the worst case) little over 24 hours. Given that our packages
update and change frequently, I think we should avoid confusion like in
Auguste's case.

On Thu, Oct 21, 2010 at 10:22 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 21.10.2010 15:56, schrieb Auguste Pop:
>> I noticed this by compiling the package myself... When I sent this
>> mail, the web page was not updated and I saw an old list of files that
>> did not contain the .so file. I should have tried it first rather than
>> relying on a presumably delayed response on the web site. Sorry for
>> the false alarm.
>
> The update of the file list in the web interface might be delayed
> compared to the update of the package data itself.
>
> Dan, what can we do here? Should a version mismatch between $repo.db and
> $repo.files cause archweb to discard the file list, stating that "There
> is currently no file list available for this package", or should archweb
> print a warning "This is a file list from an older version of this
> package and might differ from the current package". Is anything like
> this already done in archweb? Should it?
>
> Right now, the delay between updating the package info and the file list
> can be (in the worst case) little over 24 hours. Given that our packages
> update and change frequently, I think we should avoid confusion like in
> Auguste's case.

It's actually updated every 12 hours, and this is an extreme case. We
shouldn't hide the filelist for all new packages when 90% of the time
the list doesn't change. We can put a "this might be out of date"
message there quite easily, I'll look into it sometime but a feature
request/bug report would be awesome so I don't lose track of it.

-Dan

Am 21.10.2010 17:29, schrieb Dan McGee:
> On Thu, Oct 21, 2010 at 10:22 AM, Thomas Bächler <thomas@archlinux.org> wrote:
>> Right now, the delay between updating the package info and the file list
>> can be (in the worst case) little over 24 hours. Given that our packages
>> update and change frequently, I think we should avoid confusion like in
>> Auguste's case.
>
> It's actually updated every 12 hours, and this is an extreme case. We
> shouldn't hide the filelist for all new packages when 90% of the time
> the list doesn't change. We can put a "this might be out of date"
> message there quite easily, I'll look into it sometime but a feature
> request/bug report would be awesome so I don't lose track of it.

Done.
https://bugs.archlinux.org/task/21394

On Thu, 21 Oct 2010 17:22:58 +0200, Thomas Bächler
<thomas@archlinux.org> wrote:
> Am 21.10.2010 15:56, schrieb Auguste Pop:
>> I noticed this by compiling the package myself... When I sent this
>> mail, the web page was not updated and I saw an old list of files that
>> did not contain the .so file. I should have tried it first rather than
>> relying on a presumably delayed response on the web site. Sorry for
>> the false alarm.
>
> The update of the file list in the web interface might be delayed
> compared to the update of the package data itself.
>
> Dan, what can we do here? Should a version mismatch between $repo.db and
> $repo.files cause archweb to discard the file list, stating that "There
> is currently no file list available for this package", or should archweb
> print a warning "This is a file list from an older version of this
> package and might differ from the current package". Is anything like
> this already done in archweb? Should it?
>
> Right now, the delay between updating the package info and the file list
> can be (in the worst case) little over 24 hours. Given that our packages
> update and change frequently, I think we should avoid confusion like in
> Auguste's case.

ATM the file lists are created twice a day (how do you compute > 24h?)
But yes, maybe the web interface should show if there is no recent file
list available.

But if that is not super easy to implement it wont worth it as I am
rethinking the file list creation anyway. (but cannot really tell when)

--
Pierre Schmitz, https://users.archlinux.de/~pierre