[gentoo-dev] What are blocks used for?

[gentoo-dev] What are blocks used for?

[Ciaran McCreesh]

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

What all are blocks used for?

a) Marking that two unrelated packages are mutually incompatible at
runtime because they happen to collide, for example on a commonly named
executable.

b) Marking that two related implementations are mutually incompatible at
runtime because they both provide the same binary.

c) Marking that a file that used to be provided by one package is now
provided by another package that is either depending upon or depended
upon by the original package.

d) Marking that a package has been moved into another package.

Are there any other uses?

For future EAPIs, being able to tell the package manager that your
block is of one of the types above will help the package manager smooth
out the upgrade path for users. For example, for class d) blocks such
as the recent coreutils / mktemp mess, the package manager can suggest
to the user to install the new package and then uninstall the old
package, rather than forcing the user to uninstall the old package by
hand (possibly leaving their system without critical utilities) and then
install the new package.

I strongly suspect that in many (but not all) cases the package manager
could be making users' lives a lot easier than it currently is...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwin'ski"]

Ciaran McCreesh pisze:
> What all are blocks used for?
>
> a) Marking that two unrelated packages are mutually incompatible at
> runtime because they happen to collide, for example on a commonly named
> executable.
>
> b) Marking that two related implementations are mutually incompatible at
> runtime because they both provide the same binary.
>
> c) Marking that a file that used to be provided by one package is now
> provided by another package that is either depending upon or depended
> upon by the original package.
>
> d) Marking that a package has been moved into another package.
>
> Are there any other uses?
>
> For future EAPIs, being able to tell the package manager that your
> block is of one of the types above will help the package manager smooth
> out the upgrade path for users. 
Yes, but You should be able to get upgrade without crashing Your system.
> For example, for class d) blocks such
> as the recent coreutils / mktemp mess, the package manager can suggest
> to the user to install the new package and then uninstall the old
> package, rather than forcing the user to uninstall the old package by
> hand (possibly leaving their system without critical utilities) and then
> install the new package.
>   
It's good Idea until we get binary using different libs. When binaries 
are rewritten to use new libs and this makes them placed in other 
packages then emerge (as installing mechanism) _SOULD_NOT_ install that 
package until user decide what should do. Just as it is now. People are 
designed to use brain so uninstall package is no problem. This is also 
in some part warning to try revdep-rebuild because some dependencies 
could be changed. Revdep-rebuild allso should be running by emerge?
> I strongly suspect that in many (but not all) cases the package manager
> could be making users' lives a lot easier than it currently is...
>
>   
And I strongly suggest to leave old mechanism of portage, because we saw 
couple times what _GREAT_ automatic makes with distro - eg. Mandriva 
with all creators and cheap installer - couple apps not running, low 
performance.

Don't get me wrong - I also have that problems, and they make me 
nervous, but when I think what could I done by automatic replace package 
or binary then I get to thinking that everything is ok...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Luis Francisco Araujo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
| On Wed, 16 Apr 2008 07:54:48 +0200
| "Mateusz A. Mierzwin'ski" <mateuszmierzwinski@o2.pl> wrote:
|> And I strongly suggest to leave old mechanism of portage, because we
|> saw couple times what _GREAT_ automatic makes with distro - eg.
|> Mandriva with all creators and cheap installer - couple apps not
|> running, low performance.
|>
|> Don't get me wrong - I also have that problems, and they make me
|> nervous, but when I think what could I done by automatic replace
|> package or binary then I get to thinking that everything is ok...
|
| I'm not suggesting automatic anything. Here's what I am suggesting.
|
| Case A, Current Behaviour: User tries to install superfoo. User has
| foobar installed. User is presented with a big red blocking message,
| with no explanation. User has to work out that he is expected to
| uninstall foobar, then install superfoo (which is a problem if superfoo
| fails).
|
| Case A, Suggested New Behaviour: User is instead presented with
| something like this:
|
|     [block] app-misc/foobar is blocking app-misc/superfoo.
|         Explanation: foobar and superfoo both provide /usr/bin/foo
|         More information: http://www.gentoo.org/blah/blah.xml
|     [install] app-misc/superfoo
|     [uninstall] app-misc/foobar
|
|     Error: the above resolution will uninstall 1 package. To accept
|     this uninstall, use --permit-uninstalls.
|
| Case B is similar to Case A in resolution, but it's probably nice to
| make the distinction.
|
| Case C, Current Behaviour: User tries to upgrade foo. User is presented
| with a big red blocking message saying foo blocks libfoo or libfoo
| blocks foo, with no explanation (assuming it's not one of the subset of
| issues that can be solved automatically).
|
| Case C, Suggested New Behaviour: The package manager realises that so
| long as both foo and libfoo are upgraded during the same session,
| there's no real block, and the block is merely a way of getting around
| limitations in collision detection. No block is shown to the user.
|
| Case D, Current Behaviour: User tries to upgrade coreutils. User gets a
| big flashy block error saying coreutils blocks mktemp. User doesn't
| realise that the safe upgrade path is to force the package manager to
| ignore the block, then manually uninstall mktemp straight afterwards.
| User instead uninstalls mktemp, which is a moderately critical binary.
|
| Case D, Suggested New Behaviour: User is presented with something like
| this:
|
|     [block] sys-apps/coreutils is blocking sys-apps/mktemp
|         Explanation: mktemp is now part of coreutils
|         More information: http://www.gentoo.org/blah/blah.xml
|     [upgrade] sys-apps/coreutils
|     [uninstall] sys-apps/mktemp
|

Very good idea.


- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgFl1AACgkQBCmRZan6aeg9wwCdE0tOEUtinfV5iUyxqQbuKFG5
O1MAoIgUmY5HTLNMgDAaYtgKvm4Me4ru
=T31v
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Ciaran McCreesh]

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

On Wed, 16 Apr 2008 07:54:48 +0200
"Mateusz A. Mierzwin'ski" <mateuszmierzwinski@o2.pl> wrote:
> And I strongly suggest to leave old mechanism of portage, because we
> saw couple times what _GREAT_ automatic makes with distro - eg.
> Mandriva with all creators and cheap installer - couple apps not
> running, low performance.
> 
> Don't get me wrong - I also have that problems, and they make me 
> nervous, but when I think what could I done by automatic replace
> package or binary then I get to thinking that everything is ok...

I'm not suggesting automatic anything. Here's what I am suggesting.

Case A, Current Behaviour: User tries to install superfoo. User has
foobar installed. User is presented with a big red blocking message,
with no explanation. User has to work out that he is expected to
uninstall foobar, then install superfoo (which is a problem if superfoo
fails).

Case A, Suggested New Behaviour: User is instead presented with
something like this:

    [block] app-misc/foobar is blocking app-misc/superfoo.
        Explanation: foobar and superfoo both provide /usr/bin/foo
        More information: http://www.gentoo.org/blah/blah.xml
    [install] app-misc/superfoo
    [uninstall] app-misc/foobar

    Error: the above resolution will uninstall 1 package. To accept
    this uninstall, use --permit-uninstalls.

Case B is similar to Case A in resolution, but it's probably nice to
make the distinction.

Case C, Current Behaviour: User tries to upgrade foo. User is presented
with a big red blocking message saying foo blocks libfoo or libfoo
blocks foo, with no explanation (assuming it's not one of the subset of
issues that can be solved automatically).

Case C, Suggested New Behaviour: The package manager realises that so
long as both foo and libfoo are upgraded during the same session,
there's no real block, and the block is merely a way of getting around
limitations in collision detection. No block is shown to the user.

Case D, Current Behaviour: User tries to upgrade coreutils. User gets a
big flashy block error saying coreutils blocks mktemp. User doesn't
realise that the safe upgrade path is to force the package manager to
ignore the block, then manually uninstall mktemp straight afterwards.
User instead uninstalls mktemp, which is a moderately critical binary.

Case D, Suggested New Behaviour: User is presented with something like
this:

    [block] sys-apps/coreutils is blocking sys-apps/mktemp
        Explanation: mktemp is now part of coreutils
        More information: http://www.gentoo.org/blah/blah.xml
    [upgrade] sys-apps/coreutils
    [uninstall] sys-apps/mktemp

    Error: the above resolution will uninstall 1 package. To accept
    this uninstall, use --permit-uninstalls.

Note how mktemp is uninstalled *after* coreutils has been upgraded.

In none of these scenarios is it necessary to uninstall the blocked
package before installing the package doing the blocking. But such
scenarios probably exist, and ideally we'd have nice ways of dealing
with that, so I'd like to know what all the current and projected
future uses for blockers are.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] What are blocks used for?

[Donnie Berkholz]

On 06:24 Wed 16 Apr     , Ciaran McCreesh wrote:
> What all are blocks used for?
> 
> a) Marking that two unrelated packages are mutually incompatible at
> runtime because they happen to collide, for example on a commonly named
> executable.
> 
> b) Marking that two related implementations are mutually incompatible at
> runtime because they both provide the same binary.
> 
> c) Marking that a file that used to be provided by one package is now
> provided by another package that is either depending upon or depended
> upon by the original package.
> 
> d) Marking that a package has been moved into another package.
> 
> Are there any other uses?

A slight tweak that you may have already considered: a single package is 
split into multiple packages with a metabuild (named the same as the 
original single package) in a newer version -- for example, modularized 
X.

> For future EAPIs, being able to tell the package manager that your
> block is of one of the types above will help the package manager smooth
> out the upgrade path for users. For example, for class d) blocks such
> as the recent coreutils / mktemp mess, the package manager can suggest
> to the user to install the new package and then uninstall the old
> package, rather than forcing the user to uninstall the old package by
> hand (possibly leaving their system without critical utilities) and then
> install the new package.
> 
> I strongly suspect that in many (but not all) cases the package manager
> could be making users' lives a lot easier than it currently is...

Sounds like a great idea.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Michael Haubenwallner]

On Wed, 2008-04-16 at 07:34 +0100, Ciaran McCreesh wrote:
<snip>
> Case D, Current Behaviour: User tries to upgrade coreutils. User gets a
> big flashy block error saying coreutils blocks mktemp. User doesn't
> realise that the safe upgrade path is to force the package manager to
> ignore the block, then manually uninstall mktemp straight afterwards.
> User instead uninstalls mktemp, which is a moderately critical binary.

Or user uninstalls coreutils - yes, a colleague of mine actually did...

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

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

Re: [gentoo-dev] What are blocks used for?

[Branko Badrljica]

Michael Haubenwallner wrote:
> On Wed, 2008-04-16 at 07:34 +0100, Ciaran McCreesh wrote:
> <snip>
>   
>> Case D, Current Behaviour: User tries to upgrade coreutils. User gets a
>> big flashy block error saying coreutils blocks mktemp. User doesn't
>> realise that the safe upgrade path is to force the package manager to
>> ignore the block, then manually uninstall mktemp straight afterwards.
>> User instead uninstalls mktemp, which is a moderately critical binary.
>>     
>
> Or user uninstalls coreutils - yes, a colleague of mine actually did...
>
> /haubi/
>   
So did I BTW. At the time, I understood the portage as if it wanted me 
to remove coreutils in order to be replaced by mktemp.
Well, if thing says that it feels bothered by this blockage and would 
feel better if I removed it, I obliged it.
Obviously, coreutils implied something with system importance, but I 
thought that portage feels confident about it, like it is going to be 
replaced with a mktemp in a second or two anyway and portage doesn't 
need ot for itself...

Well, I was wrong, and had to make coreutils binpkg on main server and 
unpack it on "blocked" machine.

Ofcourse, server was running selinux, so this emand borrowing also a few 
libs until I could revive portage...


Regards

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

Re: [gentoo-dev] What are blocks used for?

[Ciaran McCreesh]

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

On Wed, 16 Apr 2008 09:52:13 +0200
"Mateusz A. Mierzwin'ski" <mateuszmierzwinski@o2.pl> wrote:
> Yes... and then all trashes like old libs are inside system. Other
> thing is when some files gets from one package to other. If You
> install old version of package "A" and then some of files get to
> package "A1" as an update and some part of package "A" get's into "B"
> package. When we update package "A" to "A1" we can be in trouble when
> installing automaticly B and uninstalling "A". Think about that.

Huh. I don't get what you're on about. We're discussing making the
package manager suggest and do what the user should be doing anyway
here.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwin'ski"]

Donnie Berkholz pisze:
> On 06:24 Wed 16 Apr     , Ciaran McCreesh wrote:
>   
>> What all are blocks used for?
>>
>> a) Marking that two unrelated packages are mutually incompatible at
>> runtime because they happen to collide, for example on a commonly named
>> executable.
>>
>> b) Marking that two related implementations are mutually incompatible at
>> runtime because they both provide the same binary.
>>
>> c) Marking that a file that used to be provided by one package is now
>> provided by another package that is either depending upon or depended
>> upon by the original package.
>>
>> d) Marking that a package has been moved into another package.
>>
>> Are there any other uses?
>>     
>
> A slight tweak that you may have already considered: a single package is 
> split into multiple packages with a metabuild (named the same as the 
> original single package) in a newer version -- for example, modularized 
> X.
>
>   
>> For future EAPIs, being able to tell the package manager that your
>> block is of one of the types above will help the package manager smooth
>> out the upgrade path for users. For example, for class d) blocks such
>> as the recent coreutils / mktemp mess, the package manager can suggest
>> to the user to install the new package and then uninstall the old
>> package, rather than forcing the user to uninstall the old package by
>> hand (possibly leaving their system without critical utilities) and then
>> install the new package.
>>
>> I strongly suspect that in many (but not all) cases the package manager
>> could be making users' lives a lot easier than it currently is...
>>     
>
> Sounds like a great idea.
>
> Thanks,
> Donnie
>   
Yes... and then all trashes like old libs are inside system. Other thing 
is when some files gets from one package to other. If You install old 
version of package "A" and then some of files get to package "A1" as an 
update and some part of package "A" get's into "B" package. When we 
update package "A" to "A1" we can be in trouble when installing 
automaticly B and uninstalling "A". Think about that.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Bo Ørsted Andresen]

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

On Wednesday 16 April 2008 09:56:04 Mateusz A. Mierzwiński wrote:
> My Prof from US used to say - if something is working good why we should
> replace it? When we do that we can be "sent to the tree with bananas
> straighting proposition" by OS.

I think it has been made quite clear in this thread that the current solution 
isn't "working good". Look at the cases where people mistakenly uninstalled 
coreutils instead of mktemp. Not to mention the fact that uninstalling mktemp 
before upgrading coreutils is indeed the wrong solution.

-- 
Bo Andresen
Gentoo KDE Dev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwiński"]

Donnie Berkholz pisze:
> On 06:24 Wed 16 Apr     , Ciaran McCreesh wrote:
>   
>> What all are blocks used for?
>>
>> a) Marking that two unrelated packages are mutually incompatible at
>> runtime because they happen to collide, for example on a commonly named
>> executable.
>>
>> b) Marking that two related implementations are mutually incompatible at
>> runtime because they both provide the same binary.
>>
>> c) Marking that a file that used to be provided by one package is now
>> provided by another package that is either depending upon or depended
>> upon by the original package.
>>
>> d) Marking that a package has been moved into another package.
>>
>> Are there any other uses?
>>     
>
> A slight tweak that you may have already considered: a single package is 
> split into multiple packages with a metabuild (named the same as the 
> original single package) in a newer version -- for example, modularized 
> X.
>
>   
>> For future EAPIs, being able to tell the package manager that your
>> block is of one of the types above will help the package manager smooth
>> out the upgrade path for users. For example, for class d) blocks such
>> as the recent coreutils / mktemp mess, the package manager can suggest
>> to the user to install the new package and then uninstall the old
>> package, rather than forcing the user to uninstall the old package by
>> hand (possibly leaving their system without critical utilities) and then
>> install the new package.
>>
>> I strongly suspect that in many (but not all) cases the package manager
>> could be making users' lives a lot easier than it currently is...
>>     
>
> Sounds like a great idea.
>
> Thanks,
> Donnie
>   
My Prof from US used to say - if something is working good why we should 
replace it? When we do that we can be "sent to the tree with bananas 
straighting proposition" by OS.

In PL: "możemy być wysłani na drzewo z propozycją prostowania bananów".
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Ciaran McCreesh]

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

On Wed, 16 Apr 2008 09:56:04 +0200
"Mateusz A. Mierzwiński" <mateuszmierzwinski@o2.pl> wrote:
> My Prof from US used to say - if something is working good why we
> should replace it? When we do that we can be "sent to the tree with
> bananas straighting proposition" by OS.

Blocks do not work:

* It's often not obvious what the user's supposed to do to resolve a
block.

* Once the user has worked out how to resolve the block correctly, it's
often hard to do so since resolving some blocks is best done by
forcibly ignoring the block, doing the install and then doing the
uninstall.

* It's often not obvious why a block is even there.

* They force the user to do a lot of work that isn't really necessary.
The package manager can be told how to resolve the block in many cases,
and the package manager can, with the user's permission, do all the
work is itself.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] What are blocks used for?

[Markus Rothe]

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

"Mateusz A. Mierzwiński" wrote:
> Yes, You have right but I have thinking about something like OPTION for 
> emerge or switch to enable that function. Emerge could provide two options 
> of working - with replace and with sending error. Maybe switch like 
> "--force-install"?

This is not a thread about a specific implementation of PMS. This thread is
about adding specs to PMS that allow implementations (i.e. paludis or portage
etc.) to "do it right".

-markus

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

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwiński"]

Bo Ørsted Andresen pisze:
> On Wednesday 16 April 2008 09:56:04 Mateusz A. Mierzwiński wrote:
>   
>> My Prof from US used to say - if something is working good why we should
>> replace it? When we do that we can be "sent to the tree with bananas
>> straighting proposition" by OS.
>>     
>
> I think it has been made quite clear in this thread that the current solution 
> isn't "working good". Look at the cases where people mistakenly uninstalled 
> coreutils instead of mktemp. Not to mention the fact that uninstalling mktemp 
> before upgrading coreutils is indeed the wrong solution.
>
>   
So why not to send on screen info about what to do rather then "ERROR"? 
This will only make problem with question "What to install to get 
working gentoo?". Maybe emerge should be updated by something like INFO 
about error? Like that - If emerge found TXT/HTML/MAN file in package 
directory in portage it should display it when error occurred. This 
makes more easy to get some help without package granulation changes.

like:

TREE:
/usr/portage/net-misc/asterisk-chan_unicall
    +- asterisk-chan_unicall-0.0.3_pre9.ebuild
    +- ChangeLog
    +- Manifest
    +- metadata.xml
    +- errorhelp-info.bz2

Where errorhelp-info.bz2 is manpage with errors information and repair 
infos.

I think this is good idea.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwiński"]

Ciaran McCreesh pisze:
> On Wed, 16 Apr 2008 09:56:04 +0200
> "Mateusz A. Mierzwiński" <mateuszmierzwinski@o2.pl> wrote:
>   
>> My Prof from US used to say - if something is working good why we
>> should replace it? When we do that we can be "sent to the tree with
>> bananas straighting proposition" by OS.
>>     
>
> Blocks do not work:
>
> * It's often not obvious what the user's supposed to do to resolve a
> block.
>
> * Once the user has worked out how to resolve the block correctly, it's
> often hard to do so since resolving some blocks is best done by
> forcibly ignoring the block, doing the install and then doing the
> uninstall.
>
> * It's often not obvious why a block is even there.
>
> * They force the user to do a lot of work that isn't really necessary.
> The package manager can be told how to resolve the block in many cases,
> and the package manager can, with the user's permission, do all the
> work is itself.
>
>   

Yes, You have right but I have thinking about something like OPTION for 
emerge or switch to enable that function. Emerge could provide two 
options of working - with replace and with sending error. Maybe switch 
like "--force-install"?


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

Re: [gentoo-dev] What are blocks used for?

[Bo Ørsted Andresen]

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

On Wednesday 16 April 2008 10:15:16 Mateusz A. Mierzwiński wrote:
> So why not to send on screen info about what to do rather then "ERROR"?

Please reread this entire thread. That's exactly what is being proposed. 

[...]
> I think this is good idea.

I think this is a terrible idea.

-- 
Bo Andresen
Gentoo KDE Dev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] What are blocks used for?

[Ulrich Mueller]

>>>>> On Wed, 16 Apr 2008, Ciaran McCreesh wrote:

> Blocks do not work:

> * It's often not obvious what the user's supposed to do to resolve a
> block.

> * Once the user has worked out how to resolve the block correctly,
> it's often hard to do so since resolving some blocks is best done by
> forcibly ignoring the block, doing the install and then doing the
> uninstall.

> * It's often not obvious why a block is even there.

> * They force the user to do a lot of work that isn't really
> necessary. The package manager can be told how to resolve the block
> in many cases, and the package manager can, with the user's
> permission, do all the work is itself.

I don't know if it would be feasible from a package manager point of
view, but couldn't some (most?) blockers be avoided if there was some
means to transfer ownership of installed files from one package to
another?

>> c) Marking that a file that used to be provided by one package is
>> now provided by another package that is either depending upon or
>> depended upon by the original package.

>> d) Marking that a package has been moved into another package.

At least these two common cases could then be avoided most of the
time.

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

Re: [gentoo-dev] What are blocks used for?

[Ciaran McCreesh]

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

On Wed, 16 Apr 2008 10:40:49 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> I don't know if it would be feasible from a package manager point of
> view, but couldn't some (most?) blockers be avoided if there was some
> means to transfer ownership of installed files from one package to
> another?

From a package manager point of view, it's probably easier to know that
a transfer of ownership will take place (or, more specifically, that
collisions between two packages as part of an upgrade or replace
process are ok) than to deal with specific files. It's probably easier
to write ebuilds that way too -- providing explicit lists gets very
messy if we start talking about things that include libdir or bits of
CHOST or Ruby versions or whatever in their filenames.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] What are blocks used for?

[Ciaran McCreesh]

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

On Wed, 16 Apr 2008 11:07:20 +0200
"Mateusz A. Mierzwiński" <mateuszmierzwinski@o2.pl> wrote:
> I think that this thread is about making Gentoo unstable, unusable
> and user non-friendly.

I think you really don't have the slightest clue what this thread is
about.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwiński"]

Markus Rothe pisze:
> "Mateusz A. Mierzwiński" wrote:
>   
>> Yes, You have right but I have thinking about something like OPTION for 
>> emerge or switch to enable that function. Emerge could provide two options 
>> of working - with replace and with sending error. Maybe switch like 
>> "--force-install"?
>>     
>
> This is not a thread about a specific implementation of PMS. This thread is
> about adding specs to PMS that allow implementations (i.e. paludis or portage
> etc.) to "do it right".
>
> -markus
>   
Yeah! Right...

You know what? I think that this thread is about making Gentoo unstable, 
unusable and user non-friendly. Bad things are happend in Gentoo and I 
freezing distfiles and gentoo stages on my disk. Destroy that distro as 
much as You can. See yourself at DistroWatch what place have Gentoo 
today? Couple months ago it was 7-th place, and now? People are escaping 
from Gentoo - tell me Why? Maybe because bad programing practices and 
adding something that is not needed, and most needed things are sent 
back to archive of sick people complains?

Try to hear others, not only Your pride...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Wulf C. Krueger]

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

On Wednesday, 16. April 2008 11:03:29 Ciaran McCreesh wrote:
> > I think that this thread is about making Gentoo unstable, unusable
> > and user non-friendly.
> I think you really don't have the slightest clue what this thread is
> about.

Don't feed the trolls...

-- 
Best regards, Wulf

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] What are blocks used for?

[Bernd Steinhauser]

Ciaran McCreesh schrieb:
> What all are blocks used for?
> 
> a) Marking that two unrelated packages are mutually incompatible at
> runtime because they happen to collide, for example on a commonly named
> executable.
> 
> b) Marking that two related implementations are mutually incompatible at
> runtime because they both provide the same binary.
> 
> c) Marking that a file that used to be provided by one package is now
> provided by another package that is either depending upon or depended
> upon by the original package.
> 
> d) Marking that a package has been moved into another package.
> 
> Are there any other uses?
> 
> For future EAPIs, being able to tell the package manager that your
> block is of one of the types above will help the package manager smooth
> out the upgrade path for users. For example, for class d) blocks such
> as the recent coreutils / mktemp mess, the package manager can suggest
> to the user to install the new package and then uninstall the old
> package, rather than forcing the user to uninstall the old package by
> hand (possibly leaving their system without critical utilities) and then
> install the new package.
> 
> I strongly suspect that in many (but not all) cases the package manager
> could be making users' lives a lot easier than it currently is...
> 
There is another case.

e) A package needs a newer version of another package, but doesn't depend on it.

This was the case with KDE4. kdelibs-4.0.x block these packages:
     !<kde-base/kdebase-3.5.7-r6
     !<kde-base/kdebase-startkde-3.5.7-r1
     !=kde-base/kdebase-3.5.8
     !=kde-base/kdebase-3.5.8-r1
     !=kde-base/kdebase-3.5.8-r2
     !=kde-base/kdebase-startkde-3.5.8

The reason is, that a newer revision has to be installed. (But of course 
kdelibs-4.0.x can't depend on a kde3 package.)
So in this case the behaviour would be different ((keyword and) upgrade one 
package, then install the other package) and the given block reason would be 
different.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: What are blocks used for?

[Duncan]

"Mateusz A. Mierzwin'ski" <mateuszmierzwinski@o2.pl> posted
4805B02D.2000405@o2.pl, excerpted below, on  Wed, 16 Apr 2008 09:52:13
+0200:

> Yes... and then all trashes like old libs are inside system. 

Long since solved problem.  emerge --depclean

> Other thing
> is when some files gets from one package to other. If You install old
> version of package "A" and then some of files get to package "A1" as an
> update and some part of package "A" get's into "B" package. When we
> update package "A" to "A1" we can be in trouble when installing
> automaticly B and uninstalling "A". Think about that.

Again, a long since solved problem in the context of the current 
discussion, as when package A is uninstalled, the PM verifies files 
against the package database entry for that package, and doesn't remove 
changed files.  Otherwise the normal upgrade procedure of installing the 
new then uninstalling the old wouldn't work.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[gentoo-dev] Re: What are blocks used for?

[Duncan]

"Mateusz A. Mierzwiński" <mateuszmierzwinski@o2.pl> posted
4805B65D.8050200@o2.pl, excerpted below, on  Wed, 16 Apr 2008 10:18:37
+0200:

> Yes, You have right but I have thinking about something like OPTION for
> emerge or switch to enable that function. Emerge could provide two
> options of working - with replace and with sending error. Maybe switch
> like "--force-install"?

RTFM as they say, and ask on the user list if you still don't 
understand.  This is a devel list not a user help list.  The option (in 
portage anyway) has been there for some time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

Re: [gentoo-dev] Re: What are blocks used for?

["Mateusz A. Mierzwiński"]

Duncan pisze:
> "Mateusz A. Mierzwiński" <mateuszmierzwinski@o2.pl> posted
> 4805B65D.8050200@o2.pl, excerpted below, on  Wed, 16 Apr 2008 10:18:37
> +0200:
>
>   
>> Yes, You have right but I have thinking about something like OPTION for
>> emerge or switch to enable that function. Emerge could provide two
>> options of working - with replace and with sending error. Maybe switch
>> like "--force-install"?
>>     
>
> RTFM as they say, and ask on the user list if you still don't 
> understand.  This is a devel list not a user help list.  The option (in 
> portage anyway) has been there for some time.
>
>   
And what user list will make if this is post for adding something to 
emerge mechanism? Users should do that or devs?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: What are blocks used for?

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Mateusz A. Mierzwiński,

I really appreciate your trying to help, but your command of the English language is such
that I and others have a lot of trouble making sense out of what you write. Perhaps you
should consider that you also have problems understanding Ciaran's proposal because of
this and refrain from commenting further.

Distrowatch page rankings are essentially noise. We continue to have between 900 and 1000
users in #gentoo. Try ranking that.

Thank you,

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgF8WwACgkQp/VmCx0OL2yImgCgssm1R901NwHGMjIKuzWZl5n5
PtwAoLi+u0AvuUf3Ow/X6AbdQblYdeyA
=p1+7
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Richard Freeman]

Bo Ørsted Andresen wrote:
> On Wednesday 16 April 2008 10:15:16 Mateusz A. Mierzwiński wrote:
>> So why not to send on screen info about what to do rather then "ERROR"?
> 
> Please reread this entire thread. That's exactly what is being proposed. 

I'd go one step further.  Don't tell the user what to do - just do it 
(when this is safe).

Maybe have a REPLACES="app-foo/bar" variable in ebuilds.  That tells the 
package manager that the new package supersedes the old one - any 
version of the new package is considered higher in version than any 
version of the old package.  Any cases where the new package overwrites 
files belonging to the old package are not detected as collisions.  If 
set to auto-clean the package manger unmerges the old package after 
merging the new one.  If the package manager sees the old package in 
world it will act like the new package is in world.  Basically you treat 
it like an upgrade.

This isn't always desirable, and in those cases you wouldn't use this 
functionality.

Having an ebuild output a list of steps telling the user how to work 
around a package manager limitation is really a non-ideal solution.  If 
a defined set of steps will always fix the issue, why not just do them?

And maybe have an option/FEATURE to disable this behavior, just as you 
can disable auto-cleaning in portage.  We don't tell users to manually 
clean out old versions of software, so why tell them to manually resolve 
other issues?

Again, I'm not proposing this as a fix to ALL blocks.  However, 
something like this could have made the mktemp mess a lot simpler. 
There would have been no issues to end users if the new coreutils 
silently collided with mktemp and triggered auto-removal of mktemp when 
the upgrade was done.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Richard Freeman]

Mateusz A. Mierzwin'ski wrote:
> And I strongly suggest to leave old mechanism of portage, because we saw 
> couple times what _GREAT_ automatic makes with distro - eg. Mandriva 
> with all creators and cheap installer - couple apps not running, low 
> performance.
> 
> Don't get me wrong - I also have that problems, and they make me 
> nervous, but when I think what could I done by automatic replace package 
> or binary then I get to thinking that everything is ok...

Nobody is suggesting getting rid of all blocks or automating upgrades 
that shouldn't be automated.

They're suggesting adding a little more intelligence to the current 
system.  Really safe upgrades might happen automatically.  Others might 
still fail, but would contain more informational errors.  Others might 
just continue as they do currently.

You don't complain when you upgrade from shorewall 3.4.7 to 3.4.8 and 
portage auto-uninstalls 3.4.7 when you're done, do you?  The whole point 
of a package manager is to automate routine and safe activities.  The 
alternative is manual install of tarballs...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: What are blocks used for?

["Mateusz A. Mierzwiński"]

Marijn Schouten (hkBst) pisze:
> Hello Mateusz A. MierzwiDski,
>
> I really appreciate your trying to help, but your command of the 
> English language is such
> that I and others have a lot of trouble making sense out of what you 
> write. Perhaps you
> should consider that you also have problems understanding Ciaran's 
> proposal because of
> this and refrain from commenting further.
>
> Distrowatch page rankings are essentially noise. We continue to have 
> between 900 and 1000
> users in #gentoo. Try ranking that.
>
> Thank you,
>
> Marijn
>
Hi Marijn,

I just want to know that Gentoo will be usable for me and my client's 
that I provide Gentoo Linux support. I recommending Gentoo whatever I 
can, but when I see what happens than I starting to worry.

Mateusz M.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwiński"]

Richard Freeman pisze:
> Bo Ørsted Andresen wrote:
>> On Wednesday 16 April 2008 10:15:16 Mateusz A. Mierzwiński wrote:
>>> So why not to send on screen info about what to do rather then "ERROR"?
>>
>> Please reread this entire thread. That's exactly what is being proposed. 
>
> I'd go one step further.  Don't tell the user what to do - just do it 
> (when this is safe).
>
> Maybe have a REPLACES="app-foo/bar" variable in ebuilds.  That tells 
> the package manager that the new package supersedes the old one - any 
> version of the new package is considered higher in version than any 
> version of the old package.  Any cases where the new package 
> overwrites files belonging to the old package are not detected as 
> collisions.  If set to auto-clean the package manger unmerges the old 
> package after merging the new one.  If the package manager sees the 
> old package in world it will act like the new package is in world.  
> Basically you treat it like an upgrade.
>
> This isn't always desirable, and in those cases you wouldn't use this 
> functionality.
>
> Having an ebuild output a list of steps telling the user how to work 
> around a package manager limitation is really a non-ideal solution.  
> If a defined set of steps will always fix the issue, why not just do 
> them?
>
> And maybe have an option/FEATURE to disable this behavior, just as you 
> can disable auto-cleaning in portage.  We don't tell users to manually 
> clean out old versions of software, so why tell them to manually 
> resolve other issues?
>
> Again, I'm not proposing this as a fix to ALL blocks.  However, 
> something like this could have made the mktemp mess a lot simpler. 
> There would have been no issues to end users if the new coreutils 
> silently collided with mktemp and triggered auto-removal of mktemp 
> when the upgrade was done.
This are good idea's. But i think about what You have written - when 
this is safe. I think this could make some troubles...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

["Mateusz A. Mierzwin'ski"]

Richard Freeman pisze:
> Mateusz A. Mierzwin'ski wrote:
>> And I strongly suggest to leave old mechanism of portage, because we 
>> saw couple times what _GREAT_ automatic makes with distro - eg. 
>> Mandriva with all creators and cheap installer - couple apps not 
>> running, low performance.
>>
>> Don't get me wrong - I also have that problems, and they make me 
>> nervous, but when I think what could I done by automatic replace 
>> package or binary then I get to thinking that everything is ok...
>
> Nobody is suggesting getting rid of all blocks or automating upgrades 
> that shouldn't be automated.
>
> They're suggesting adding a little more intelligence to the current 
> system.  Really safe upgrades might happen automatically.  Others 
> might still fail, but would contain more informational errors.  Others 
> might just continue as they do currently.
>
> You don't complain when you upgrade from shorewall 3.4.7 to 3.4.8 and 
> portage auto-uninstalls 3.4.7 when you're done, do you?  The whole 
> point of a package manager is to automate routine and safe 
> activities.  The alternative is manual install of tarballs...
And tell me, why whole day _no_one_ could wrote that like this? Thanks 
for info.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Petteri Räty]

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

Mateusz A. Mierzwin'ski kirjoitti:
> Richard Freeman pisze:
>> Mateusz A. Mierzwin'ski wrote:
>>> And I strongly suggest to leave old mechanism of portage, because we 
>>> saw couple times what _GREAT_ automatic makes with distro - eg. 
>>> Mandriva with all creators and cheap installer - couple apps not 
>>> running, low performance.
>>>
>>> Don't get me wrong - I also have that problems, and they make me 
>>> nervous, but when I think what could I done by automatic replace 
>>> package or binary then I get to thinking that everything is ok...
>>
>> Nobody is suggesting getting rid of all blocks or automating upgrades 
>> that shouldn't be automated.
>>
>> They're suggesting adding a little more intelligence to the current 
>> system.  Really safe upgrades might happen automatically.  Others 
>> might still fail, but would contain more informational errors.  Others 
>> might just continue as they do currently.
>>
>> You don't complain when you upgrade from shorewall 3.4.7 to 3.4.8 and 
>> portage auto-uninstalls 3.4.7 when you're done, do you?  The whole 
>> point of a package manager is to automate routine and safe 
>> activities.  The alternative is manual install of tarballs...
> And tell me, why whole day _no_one_ could wrote that like this? Thanks 
> for info.

Because for Gentoo developers it should be quite evident what the thread 
was really about and this is not an educational list (we have 
gentoo-user for that). To me it seems you misunderstood the topic all 
the way. Responding in private to try and keep noise out of the public 
mailing list.

Regards,
Petteri


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

Re: [gentoo-dev] Re: What are blocks used for?

[Andrej Kacian]

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

On Wed, 16 Apr 2008 18:59:26 +0200
"Mateusz A. Mierzwiński" <mateuszmierzwinski@o2.pl> wrote:

> I just want to know that Gentoo will be usable for me and my client's 
> that I provide Gentoo Linux support. I recommending Gentoo whatever I 
> can, but when I see what happens than I starting to worry.

If you really saw what is happening in this thread (other than noise created
by yourself), you would understand that it will make Gentoo better by handling
blocks more gracefully and in a much more user-friendly way.

Regards,
-- 
Andrej "Ticho" Kacian <ticho at gentoo dot org>
Gentoo Linux Developer - net-mail, antivirus, x86

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

Re: [gentoo-dev] What are blocks used for?

[Dawid Węgliński]

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

Wednesday, 16 of April 2008 11:07:20 Mateusz A. Mierzwiński wrote:
> Markus Rothe pisze:
> > "Mateusz A. Mierzwiński" wrote:
> >> Yes, You have right but I have thinking about something like OPTION for
> >> emerge or switch to enable that function. Emerge could provide two
> >> options of working - with replace and with sending error. Maybe switch
> >> like "--force-install"?
> >
> > This is not a thread about a specific implementation of PMS. This thread
> > is about adding specs to PMS that allow implementations (i.e. paludis or
> > portage etc.) to "do it right".
> >
> > -markus
>
> Yeah! Right...
>
> You know what? I think that this thread is about making Gentoo unstable,
> unusable and user non-friendly. Bad things are happend in Gentoo and I
> freezing distfiles and gentoo stages on my disk. Destroy that distro as
> much as You can. See yourself at DistroWatch what place have Gentoo
> today? Couple months ago it was 7-th place, and now? People are escaping
> from Gentoo - tell me Why? Maybe because bad programing practices and
> adding something that is not needed, and most needed things are sent
> back to archive of sick people complains?
>
> Try to hear others, not only Your pride...

Cześć Mateusz.

Myślę, że źle rozumiesz założenia pomysłu, który został zaproponowany przez 
Ciarana. Zrozum, że chodzi o to, żeby menadżer pakietów potrafił rozwiązywać 
problemy pakietów wzajemnie się blokujących i podawał użytkownikowi 
informację dlaczego taki blok istnieje i jak się go pozbyć. Nie twierdzę, że 
nie masz racji, nie twierdzę też, że ją masz. Ale patrząc na cały temat 
jesteś jedyną osobą, która twardo się przeciwstawia pomysłowi nie podając 
żadnych argumentów. Ponadto, bez obrazy, ale poziom Twojego języka nie jest 
być może na tyle dobry, żeby inni Cię mogli zrozumieć (robisz błędy 
gramatyczne itp.). Postaraj się przeczytać tę dyskusję ponownie i zrozumieć 
założenie pomysłu. Tu [1] masz adres do archiwum.


[1] - 
http://archives.gentoo.org/gentoo-dev/msg_e7f929ecc22ca5bf67fc80e78e5aaa16.xml

-- 
Cheers
Dawid Węgliński

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] What are blocks used for?

[Enrico Weigelt]

* Ciaran McCreesh <ciaran.mccreesh@googlemail.com> schrieb:

Hi,

> b) Marking that two related implementations are mutually incompatible at
> runtime because they both provide the same binary.

Classical example: MTA's:

Traditionally they tend to provide an /usr/sbin/sendmail executable.
So you can't have multiple MTAs installed. Here the problem isn't
that portage can't give more advise, but the system only allows
one MTA. Portage itself can't help here in any ways - it's all up 
to the ebuilds. An clean solution is changing the MTAs to be not
conflicting (using separate filenames, etc) and having some frontend
for these commands, which chooses the right MTA to call on some
configuration. 

AFAIK, this is exactly what mailwrapper does :)

Same applies to things like java-config, etc.

> c) Marking that a file that used to be provided by one package is now
> provided by another package that is either depending upon or depended
> upon by the original package.

Do you mean something like this ?

* package foo 	-> has: /usr/bin/foo
* package bar	-> depends: foo
		-> has: /usr/bin/foo 
		 
> For example, for class d) blocks such as the recent coreutils / mktemp mess, 

Yes, this is *really* a mess, especially because critical packages are
involved here.

IMHO the problem is clearly made by the two packages themselves.
Actually I didn't track yet who was first, but according to the ebuilds,
the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp
should be preferred and the coreutils's one skipped.

> the package manager can suggest to the user to install the new package and 
> then uninstall the old package, rather than forcing the user to uninstall 
> the old package by hand (possibly leaving their system without critical 
> utilities) and then install the new package.

Yes, but this requires the ebuild author to provide enough information 
*very carefully*. In this specific case, portage could automatically 
decide to replace the separate mktemp package by newer coreutils. 
But what happens if some package depends on the mktemp package ? 
Portage has to catch these deps and map them to coreutils if they 
provide mktemp (and only for those versions which *really do*).
This all adds a lot of complexity, and I doubt it's really worth it.

Removing mktemp and properly maintaining the standalone package seems 
much easier and cleaner to me.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Vlastimil Babka]

Enrico Weigelt wrote:
> * Ciaran McCreesh <ciaran.mccreesh@googlemail.com> schrieb:
> 
> Hi,

Hi Enrico, long time no see!

>> b) Marking that two related implementations are mutually incompatible at
>> runtime because they both provide the same binary.
> 
> Classical example: MTA's:
> 
> Traditionally they tend to provide an /usr/sbin/sendmail executable.
> So you can't have multiple MTAs installed. Here the problem isn't
> that portage can't give more advise, but the system only allows

I see you've been missing this list for a long time. Today it's not 
politically correct to say bluntly "portage" but "package manager" (PM)!

>> For example, for class d) blocks such as the recent coreutils / mktemp mess, 
> 
> Yes, this is *really* a mess, especially because critical packages are
> involved here.
> 
> IMHO the problem is clearly made by the two packages themselves.
> Actually I didn't track yet who was first, but according to the ebuilds,
> the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp
> should be preferred and the coreutils's one skipped.

Um no, we should not stick with packages forever for historical reasons.

>> the package manager can suggest to the user to install the new package and 
>> then uninstall the old package, rather than forcing the user to uninstall 
>> the old package by hand (possibly leaving their system without critical 
>> utilities) and then install the new package.
> 
> Yes, but this requires the ebuild author to provide enough information 
> *very carefully*.

Yes, ebuild author should be careful, OTOH the end users wouldn't have 
to be as much careful as they had to be now when dealing with it themselves.

> In this specific case, portage could automatically 
> decide to replace the separate mktemp package by newer coreutils. 
> But what happens if some package depends on the mktemp package ? 

Such deps should obviously be transformed to || ( >=coreutils-6.10 
mktemp) beforehand.

> Portage has to catch these deps and map them to coreutils if they 
> provide mktemp (and only for those versions which *really do*).

No, it should probably just state there's a dep conflict (as it does now 
if there are several depends asking for different versions inside one slot).

> This all adds a lot of complexity, and I doubt it's really worth it.

Stating dep conflict should be less complexity, and yes it's worth it.

> Removing mktemp and properly maintaining the standalone package seems 
> much easier and cleaner to me.

Sure, legacy and maintainership burden ftw!
I'm tempted to say "we are not debian" but since I'm not council... :(

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

Re: [gentoo-dev] What are blocks used for?

[Enrico Weigelt]

* Donnie Berkholz <dberkholz@gentoo.org> schrieb:

> A slight tweak that you may have already considered: a single package is 
> split into multiple packages with a metabuild (named the same as the 
> original single package) in a newer version -- for example, modularized 
> X.

hmm, let's just thing through this:

foo-1.0 (monolithic) is installed.
foo-2.0 (spliited) should come in by update, depends on fooA and fooB.
Obviously fooA and fooB will conflict with foo-1.0.

How does portage actually behave on "merge -u foo" ?

IMHO, it would block on foo(A|B) vs. installed foo-1.0, since it handles
each package separately. 

To solve this cleanly (and automatically), we'll end up in an transactional 
requirement: the whole emerge tree (or at least critical parts of it) run 
in their own dedicated environment (sysroot) and are committed in an atomic 
step - merging to the running system happens *only* if everything worked 
fine (maybe optionally including etc-update ?) and so never leaves the 
system in inconsistent state if someting goes wrong in the middle of 
this process.

But, ugh, that's perhaps far too much for the current portage approach ;-o
(I'm actually doing so with my own "Briegel" build system, which is designed
for embedded and crititcal targets)

> > I strongly suspect that in many (but not all) cases the package manager
> > could be making users' lives a lot easier than it currently is...
> 
> Sounds like a great idea.

ACK. At least there should be some mechanism to tell the user why
exactly this block happened and suggestions how to solve this
(of course, manually written by the ebuild authors). Simply adding
some file per conflict to be printed out should be enough, IMHO.
Maybe this filename could be added in {} directly behind each
invididual dep.

For the example above it could look like this:

fooA-2.0.ebuild:
----

...
DEPENDS="!foo<2.0{$FILESDIR}/upgrade-from-1.0.inf"
...

files/upgrade-from-1.0.inf:
----

TYPE: pkg-split, src=foo
SPLIT-SRC: foo>=2.0
SPLIT-PARTS: fooA, fooB  
INFO: By version 2.0, foo has been split into the packages fooA and fooB.
INFO: The build process can't run directly, since the new sub packages 
INFO: conflict with the already installed monolithic version within the 
INFO: build process. 
INFO: Removing foo and installing it afresh will solve this conflict.


As you see, the "INFO: "-Lines are what's printed out to the user,
while the other lines could help portage to solve it automatically
(if it has an special logic for this)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Enrico Weigelt]

* Bernd Steinhauser <gentoo@bernd-steinhauser.de> schrieb:

Hi,

> e) A package needs a newer version of another package, but doesn't depend 
> on it.
> 
> This was the case with KDE4. kdelibs-4.0.x block these packages:
>     !<kde-base/kdebase-3.5.7-r6
>     !<kde-base/kdebase-startkde-3.5.7-r1
>     !=kde-base/kdebase-3.5.8
>     !=kde-base/kdebase-3.5.8-r1
>     !=kde-base/kdebase-3.5.8-r2
>     !=kde-base/kdebase-startkde-3.5.8

I don't know very much about KDE stuff, since I got rid of it for 
a long time, but IMHO it seems there's an principle problem on 
the install layout - 3.x and 4.x should be completely separate,
never conflicting each other. So some package kfoo either depends
on kdelibfoo-3.x OR kdelibfoo-4.x.

Of course I don't know whether the problems comes from ebuilds 
or upstream ;-o

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Enrico Weigelt]

* Ulrich Mueller <ulm@gentoo.org> schrieb:

> I don't know if it would be feasible from a package manager point of
> view, but couldn't some (most?) blockers be avoided if there was some
> means to transfer ownership of installed files from one package to
> another?

This is problematic, since the system must be in an consistent
state after the update, or really bad things can happen.
And it still doesn't solve dependencies correctly, imagine:

foo1: depends on bar1
foo2: depends on bar2
bar1 and bar2 are in conflict.

For the special case of one package replacing another one *completely*
(eg. the mktemp case), the process could be automated by giving
portage enough information and having appropriate logic in portage).

But is it really worth all that ? 

In the mktemp case, IMHO, coreutils is the source of evil:
it simply assimilated another package !
We shouldn't let it pass.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] What are blocks used for?

[Vlastimil Babka]

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

Enrico Weigelt wrote:
> * Ciaran McCreesh <ciaran.mccreesh@googlemail.com> schrieb:
> 
> Hi,

Hi Enrico, long time no see!

>> b) Marking that two related implementations are mutually incompatible at
>> runtime because they both provide the same binary.
> 
> Classical example: MTA's:
> 
> Traditionally they tend to provide an /usr/sbin/sendmail executable.
> So you can't have multiple MTAs installed. Here the problem isn't
> that portage can't give more advise, but the system only allows

I see you've been missing this list for a long time. Today it's not
politically correct to say bluntly "portage" but "package manager" (PM)! 
(the kind reader can then usually substitue implementation name 
depending on the e-mail sender)

>> For example, for class d) blocks such as the recent coreutils / mktemp mess, 
> 
> Yes, this is *really* a mess, especially because critical packages are
> involved here.
> 
> IMHO the problem is clearly made by the two packages themselves.
> Actually I didn't track yet who was first, but according to the ebuilds,
> the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp
> should be preferred and the coreutils's one skipped.

Um no, we should not stick with packages forever for historical reasons.

>> the package manager can suggest to the user to install the new package and 
>> then uninstall the old package, rather than forcing the user to uninstall 
>> the old package by hand (possibly leaving their system without critical 
>> utilities) and then install the new package.
> 
> Yes, but this requires the ebuild author to provide enough information 
> *very carefully*.

Yes, ebuild author should be careful, OTOH the end users wouldn't have
to be as much careful as they had to be now when dealing with it themselves.

> In this specific case, portage could automatically 
> decide to replace the separate mktemp package by newer coreutils. 
> But what happens if some package depends on the mktemp package ? 

Such deps should obviously be transformed to || ( >=coreutils-6.10
mktemp) beforehand.

> Portage has to catch these deps and map them to coreutils if they 
> provide mktemp (and only for those versions which *really do*).

No, it should probably just state there's a dep conflict (as it does now
if there are several depends asking for different versions inside one slot).

> This all adds a lot of complexity, and I doubt it's really worth it.

Stating dep conflict should be less complexity, and yes it's worth it.

> Removing mktemp and properly maintaining the standalone package seems 
> much easier and cleaner to me.

Sure, legacy and maintainership burden ftw! Including backporting 
security fixes!
I'm tempted to say "we are not debian" but since I'm not council... :(

Caster



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

Re: [gentoo-dev] What are blocks used for?

[Vlastimil Babka]

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

Enrico Weigelt wrote:
> * Bernd Steinhauser <gentoo@bernd-steinhauser.de> schrieb:
> 
> Hi,
> 
>> e) A package needs a newer version of another package, but doesn't depend 
>> on it.
>>
>> This was the case with KDE4. kdelibs-4.0.x block these packages:
>>     !<kde-base/kdebase-3.5.7-r6
>>     !<kde-base/kdebase-startkde-3.5.7-r1
>>     !=kde-base/kdebase-3.5.8
>>     !=kde-base/kdebase-3.5.8-r1
>>     !=kde-base/kdebase-3.5.8-r2
>>     !=kde-base/kdebase-startkde-3.5.8
> 
> I don't know very much about KDE stuff, since I got rid of it for 
> a long time, but IMHO it seems there's an principle problem on 
> the install layout - 3.x and 4.x should be completely separate,
> never conflicting each other. So some package kfoo either depends
> on kdelibfoo-3.x OR kdelibfoo-4.x.
> 
> Of course I don't know whether the problems comes from ebuilds 
> or upstream ;-o

If you don't know why the blocks nned to be there then why comment on that?
-- 
Vlastimil Babka (Caster)
Gentoo/Java


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

[gentoo-dev] Re: What are blocks used for?

[Duncan]

Enrico Weigelt <weigelt@metux.de> posted
20080417195145.GJ31409@nibiru.local, excerpted below, on  Thu, 17 Apr 2008
21:51:45 +0200:

> I don't know very much about KDE stuff, since I got rid of it for a long
> time, but IMHO it seems there's an principle problem on the install
> layout - 3.x and 4.x should be completely separate, never conflicting
> each other. So some package kfoo either depends on kdelibfoo-3.x OR
> kdelibfoo-4.x.
> 
> Of course I don't know whether the problems comes from ebuilds or
> upstream ;-o

The problem is simply older versions of kde-3 ebuilds.  Newer versions 
have the plumbing necessary to keep v3 and v4 separate, but older 
versions didn't.  So those blocks are on the older versions that didn't.  
By the time kde4 stabilizes (quite some time as a qualified upstream 
version isn't released yet, current kde4 will never stabilize), the newer 
kde3 ebuilds should have been stable for some time, so the blocks are 
there just in case someone has a real outdated kde3 system and tries to 
install kde4 as well.  If they are going to keep their kde3, they'll need 
to update it first, to the ebuilds that handle things correctly.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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