[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]

"Hanno Boeck (hanno)" <hanno@gentoo.org> said:
> hanno       07/11/06 01:01:35
> 
>   Modified:             4Q-2007
>   Log:
>   move beryl packages to their corresponding compiz fusion packages
> 
> Revision  Changes    Path
> 1.10                 profiles/updates/4Q-2007
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10&content-type=text/plain
> diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?r1=1.9&r2=1.10
> 
> Index: 4Q-2007
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/profiles/updates/4Q-2007,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- 4Q-2007	3 Nov 2007 15:35:36 -0000	1.9
> +++ 4Q-2007	6 Nov 2007 01:01:35 -0000	1.10
> @@ -8,3 +8,10 @@
>  move x11-apps/compiz-settings x11-apps/ccsm
>  move x11-plugins/compiz-extra x11-plugins/compiz-fusion-plugins-main
>  slotmove =app-emulation/emul-linux-x86-java-1.4* 1.4.2 1.4
> +move x11-wm/beryl x11-wm/compiz-fusion
> +move x11-wm/beryl-core x11-wm/compiz
> +move x11-plugins/beryl-plugins x11-plugins/compiz-fusion-plugins-main
> +move x11-plugins/beryl-dbus x11-plugins/compiz-fusion-plugins-extra
> +move x11-misc/beryl-settings-bindings x11-libs/compizconfig-python
> +move x11-misc/beryl-settings x11-libs/libcompizconfig
> +move x11-misc/beryl-manager x11-apps/ccsm

Just to get a wider audience involved in this...this just seems wrong to
do.  There is a QA bug open about it as well:
https://bugs.gentoo.org/show_bug.cgi?id=198248

What are other people's feelings on using package moves to forcibly
migrate people like this?  It also sounds like this wasn't announced at
all and the packages just left the tree.

-- 
Mark Loeser
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007

[Doug Klima]

Mark Loeser wrote:
> "Hanno Boeck (hanno)" <hanno@gentoo.org> said:
>   
>> hanno       07/11/06 01:01:35
>>
>>   Modified:             4Q-2007
>>   Log:
>>   move beryl packages to their corresponding compiz fusion packages
>>
>> Revision  Changes    Path
>> 1.10                 profiles/updates/4Q-2007
>>
>> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10&view=markup
>> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10&content-type=text/plain
>> diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?r1=1.9&r2=1.10
>>
>> Index: 4Q-2007
>> ===================================================================
>> RCS file: /var/cvsroot/gentoo-x86/profiles/updates/4Q-2007,v
>> retrieving revision 1.9
>> retrieving revision 1.10
>> diff -u -r1.9 -r1.10
>> --- 4Q-2007	3 Nov 2007 15:35:36 -0000	1.9
>> +++ 4Q-2007	6 Nov 2007 01:01:35 -0000	1.10
>> @@ -8,3 +8,10 @@
>>  move x11-apps/compiz-settings x11-apps/ccsm
>>  move x11-plugins/compiz-extra x11-plugins/compiz-fusion-plugins-main
>>  slotmove =app-emulation/emul-linux-x86-java-1.4* 1.4.2 1.4
>> +move x11-wm/beryl x11-wm/compiz-fusion
>> +move x11-wm/beryl-core x11-wm/compiz
>> +move x11-plugins/beryl-plugins x11-plugins/compiz-fusion-plugins-main
>> +move x11-plugins/beryl-dbus x11-plugins/compiz-fusion-plugins-extra
>> +move x11-misc/beryl-settings-bindings x11-libs/compizconfig-python
>> +move x11-misc/beryl-settings x11-libs/libcompizconfig
>> +move x11-misc/beryl-manager x11-apps/ccsm
>>     
>
> Just to get a wider audience involved in this...this just seems wrong to
> do.  There is a QA bug open about it as well:
> https://bugs.gentoo.org/show_bug.cgi?id=198248
>
> What are other people's feelings on using package moves to forcibly
> migrate people like this?  It also sounds like this wasn't announced at
> all and the packages just left the tree.
>
>   
Except the packages referenced are simply the same upstream project just
renamed... so it is correct.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Mark Loeser kirjoitti:
> 
> What are other people's feelings on using package moves to forcibly
> migrate people like this?  It also sounds like this wasn't announced at
> all and the packages just left the tree.
> 

Using package moves like this causes for example the following problem.
If you now depend on just x11-libs/libcompizconfig you really can't be
sure that the user has libcompizconfig files on his system because it's
enough that the files from beryl-settings are there. As such building
stuff will fail. Stuff does work as long as
>=x11-libs/libcompizconfig-0.6. for example is used everywhere.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007

[Marius Mauch]

On Tue, 6 Nov 2007 11:15:12 -0500
Mark Loeser <mark@halcy0n.com> wrote:

> Just to get a wider audience involved in this...this just seems wrong
> to do.  There is a QA bug open about it as well:
> https://bugs.gentoo.org/show_bug.cgi?id=198248
> 
> What are other people's feelings on using package moves to forcibly
> migrate people like this?  It also sounds like this wasn't announced
> at all and the packages just left the tree.

A package move via "update" file is simply an extension of a mv
command. If you also had to edit the ebuild a package move is generally
not the right thing to do. Remember that a package move applies to all
versions of a package, and upstream name changes are generally tied to
specific versions.

Marius
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)

[Jim Ramsay]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

Whether or not 'move' was the correct action in the recent compiz
example, perhaps we need to consider that some times one package does
actually make another obsolete. The correct thing for the PM to
do is to first uninstall the obsolete package, then install the new one.

Now, it has been my experience that blocking dependencies are currently
used to imply this "No, you have to remove cat/foo first before
installing cat/bar instead" situation.  This is somewhat annoying for
me when I want to upgrade a bunch of packages, but I have to manually
uninstall a few blockers first before this is possible.

This could be automated by the PM in those cases with some sort of
thing like this in the cat/bar-1.0.ebuild:

  OBSOLETES="cat/foo"

Of course this would be a regular package atom (or list thereof), so it
could be tied to specific versions of cat/foo.

I suppose this could be seen as a special case of blocking deps which
would automate a specific "cat/bar is to be preferred over cat/foo"

However, I'm not exactly sure what you would do if you have pkg1 which
depends on cat/foo and pkg2 which depends on cat/bar...

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)

[Steve Long]

Jim Ramsay wrote:

> Whether or not 'move' was the correct action in the recent compiz
> example, perhaps we need to consider that some times one package does
> actually make another obsolete. The correct thing for the PM to
> do is to first uninstall the obsolete package, then install the new one.
>
I don't think it was, for the reasons stated on the bug, and based on what
Mr Mauch has just said.

> Now, it has been my experience that blocking dependencies are currently
> used to imply this "No, you have to remove cat/foo first before
> installing cat/bar instead" situation.  This is somewhat annoying for
> me when I want to upgrade a bunch of packages, but I have to manually
> uninstall a few blockers first before this is possible.
>
You can use a script to automate that [1] so it's just a question of
pressing any key to unmerge (depending on the block; it might not actually
apply by the time you come to the blocked app.)

> This could be automated by the PM in those cases with some sort of
> thing like this in the cat/bar-1.0.ebuild:
> 
>   OBSOLETES="cat/foo"
> 
> Of course this would be a regular package atom (or list thereof), so it
> could be tied to specific versions of cat/foo.
>
I really like that idea. (A RECOMMENDS thing similar to debian would be nice
too.)

> I suppose this could be seen as a special case of blocking deps which
> would automate a specific "cat/bar is to be preferred over cat/foo"
> 
> However, I'm not exactly sure what you would do if you have pkg1 which
> depends on cat/foo and pkg2 which depends on cat/bar...
> 
That kinda sounds like the same issue genone was raising; since the
difference upstream is tied to a version, whereas the Gentoo package names
apply to all versions there can be no guarantee of compatibility. Maybe you
could get round this by only using versioned deps. (So a package move
script would have to ensure nothing had an unversioned dep on either
package.)

[1] http://forums.gentoo.org/viewtopic-t-546828.html
    New, improved-- shiny! ;D


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)

[Santiago M. Mola]

On Nov 7, 2007 3:09 PM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Jim Ramsay wrote:
>
> > This could be automated by the PM in those cases with some sort of
> > thing like this in the cat/bar-1.0.ebuild:
> >
> >   OBSOLETES="cat/foo"
> >
> > Of course this would be a regular package atom (or list thereof), so it
> > could be tied to specific versions of cat/foo.
> >
> I really like that idea. (A RECOMMENDS thing similar to debian would be nice
> too.)
>

Agreed. Recomendation could be queried in a standarised way and at any
time (not only after installing a package). It'd be more reliable than
current pkg_postinst messages.

Regards,
Santiago

-- 
Santiago M. Mola
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)

[Jeroen Roovers]

On Tue, 6 Nov 2007 16:23:35 -0500
Jim Ramsay <lack@gentoo.org> wrote:

> Whether or not 'move' was the correct action in the recent compiz
> example, perhaps we need to consider that some times one package does
> actually make another obsolete. The correct thing for the PM to
> do is to first uninstall the obsolete package, then install the new
> one.

>snip<

I don't see anything in your suggestion that requires an EAPI bump to
implement this. If the only thing you add to your ebuilds is the
OBSOLETES variable, then a PM which doesn't recognise the enhancement
will simply ignore it. In other words, OBSOLETE would not obsolete
the proper negative DEPENDs (blockers) that are currently used.

If you want to, say, make switching sysloggers easier by
offering to uninstall metalog when the admin asks to emerge syslog-ng,
then an EAPI bump would be warranted (and the proposal should be
thought through a lot more thoroughly, because as of now, emerging
one package and unmerging another are strictly separate actions and
that should perhaps never change).


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list