Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-16 Thread Peter Volkov
В Пнд, 14/01/2008 в 02:10 +0200, Petteri Räty пишет:
 Mike Frysinger kirjoitti:
  On Sunday 13 January 2008, Petteri Räty wrote:
  Peter Volkov kirjoitti:
  Also why not just do package move for libdts to avoid manual unmerge
  libdts?
  Package moves don't work very well if you move an existing package to
  another.
  
  unless they had a block in place ...
  -mike
 
 When you move a package over an another the files don't change. So 
 Portage thinks you have libdca installed but the files are from libdts. 
 So every depending on libdca would have to have their atoms in such a 
 way that doesn't match libdts existing versions. Please correct me if I 
 am wrong.

Thank you, now I see. And if I understood correctly to fix atoms you
just have to add =media-libs/libdca-0.0.5 into DEPEND of packages which
depend only on libdca. After this package move will work as it should.
Did I miss anything?

Mike, how blocks help here?

-- 
Peter.


signature.asc
Description: Эта	 часть	 сообщения	 подписана	 цифровой	 подписью


Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-16 Thread Mike Frysinger
On Wednesday 16 January 2008, Peter Volkov wrote:
 В Пнд, 14/01/2008 в 02:10 +0200, Petteri Räty пишет:
  Mike Frysinger kirjoitti:
   On Sunday 13 January 2008, Petteri Räty wrote:
   Peter Volkov kirjoitti:
   Also why not just do package move for libdts to avoid manual unmerge
   libdts?
  
   Package moves don't work very well if you move an existing package to
   another.
  
   unless they had a block in place ...
 
  When you move a package over an another the files don't change. So
  Portage thinks you have libdca installed but the files are from libdts.
  So every depending on libdca would have to have their atoms in such a
  way that doesn't match libdts existing versions. Please correct me if I
  am wrong.

 Thank you, now I see. And if I understood correctly to fix atoms you
 just have to add =media-libs/libdca-0.0.5 into DEPEND of packages which
 depend only on libdca. After this package move will work as it should.
 Did I miss anything?

 Mike, how blocks help here?

if two packages provide the same binary and they blocked each other, a move 
would be doable as it would be impossible for the two packages to be 
installed simultaneously.  but as Petteri points out, libdca/libdts dont 
provide the same SONAME so a package move wouldnt be possible.
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-16 Thread Peter Volkov
В Срд, 16/01/2008 в 06:09 -0500, Mike Frysinger пишет:
 if two packages provide the same binary and they blocked each other, a move 
 would be doable as it would be impossible for the two packages to be 
 installed simultaneously.  but as Petteri points out, libdca/libdts dont 
 provide the same SONAME so a package move wouldnt be possible.

Does this requirement stay for programs? I saw we moved ethereal to
wireshark. Was that wrong? Do we have any mechanism to indicate that the
package was renamed and upgrading should continue with another package?

-- 
Peter.


signature.asc
Description: Эта	 часть	 сообщения	 подписана	 цифровой	 подписью


Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-16 Thread Petteri Räty

Peter Volkov kirjoitti:

В Пнд, 14/01/2008 в 02:10 +0200, Petteri Räty пишет:

Mike Frysinger kirjoitti:

On Sunday 13 January 2008, Petteri Räty wrote:

Peter Volkov kirjoitti:

Also why not just do package move for libdts to avoid manual unmerge
libdts?

Package moves don't work very well if you move an existing package to
another.

unless they had a block in place ...
-mike
When you move a package over an another the files don't change. So 
Portage thinks you have libdca installed but the files are from libdts. 
So every depending on libdca would have to have their atoms in such a 
way that doesn't match libdts existing versions. Please correct me if I 
am wrong.


Thank you, now I see. And if I understood correctly to fix atoms you
just have to add =media-libs/libdca-0.0.5 into DEPEND of packages which
depend only on libdca. After this package move will work as it should.
Did I miss anything?



This requirement would always have to be used and people writing ebuilds 
a year from now aren't very likely to know about the move history so 
it's better not to use package moves for situations like this.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-16 Thread Mike Frysinger
On Wednesday 16 January 2008, Peter Volkov wrote:
 В Срд, 16/01/2008 в 06:09 -0500, Mike Frysinger пишет:
  if two packages provide the same binary and they blocked each other, a
  move would be doable as it would be impossible for the two packages to be
  installed simultaneously.  but as Petteri points out, libdca/libdts dont
  provide the same SONAME so a package move wouldnt be possible.

 Does this requirement stay for programs? I saw we moved ethereal to
 wireshark. Was that wrong? Do we have any mechanism to indicate that the
 package was renamed and upgrading should continue with another package?

for libraries with changed SONAMEs, it's def a no-no.  for programs, it's up 
for debate, especially considering with the wireshark rename, you most likely 
had an upgrade right after.  the automatic package move = upgrade is a much 
nicer user upgrade experience than a blocker.  for the edge case where the 
package was installed but not in world, you could argue that the lack of an 
automatic upgrade is still ok since even unmoved, it would have not triggered 
the block/upgrade step.
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-13 Thread Samuli Suominen
On Sun, 13 Jan 2008 13:28:36 +0300
Peter Volkov [EMAIL PROTECTED] wrote:

 В Вск, 13/01/2008 в 11:06 +0200, Samuli Suominen пишет:
  # Samuli Suominen [EMAIL PROTECTED] (13 Jan 2008)
  # Masked for removal in about 60 days.
  # libdts is replaced by libdca.
  media-libs/libdts
  =media-video/ffmpeg-0.4.9_p20051216
  =media-video/ffmpeg-0.4.9_p2006*
  =media-video/ffmpeg-0.4.9_p20070129
  =media-video/ffmpeg-0.4.9_p20070325
  =media-video/ffmpeg-0.4.9_p20070330
 
 Samuli, why do you announce ffmpeg while this looks like just removal
 of old versions?
 
 Also why not just do package move for libdts to avoid manual unmerge
 libdts?
 

On purpose. There are likely people still using one or two of these
ffmpeg versions and they need adjustment period (note the extra 30 days)

-drac
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-13 Thread Petteri Räty

Peter Volkov kirjoitti:


Also why not just do package move for libdts to avoid manual unmerge
libdts?



Package moves don't work very well if you move an existing package to 
another.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-13 Thread Mike Frysinger
On Sunday 13 January 2008, Petteri Räty wrote:
 Peter Volkov kirjoitti:
  Also why not just do package move for libdts to avoid manual unmerge
  libdts?

 Package moves don't work very well if you move an existing package to
 another.

unless they had a block in place ...
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] lastrite media-libs/libdts

2008-01-13 Thread Petteri Räty

Mike Frysinger kirjoitti:

On Sunday 13 January 2008, Petteri Räty wrote:

Peter Volkov kirjoitti:

Also why not just do package move for libdts to avoid manual unmerge
libdts?

Package moves don't work very well if you move an existing package to
another.


unless they had a block in place ...
-mike


When you move a package over an another the files don't change. So 
Portage thinks you have libdca installed but the files are from libdts. 
So every depending on libdca would have to have their atoms in such a 
way that doesn't match libdts existing versions. Please correct me if I 
am wrong.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature