What are blocks used for?

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

What are blocks used for?

Ciaran McCreesh-4
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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

"Mateusz A. Mierzwiń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...
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Ciaran McCreesh-4
On Wed, 16 Apr 2008 07:54:48 +0200
"Mateusz A. Mierzwin'ski" <[hidden email]> 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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email]> 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-----
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Donnie Berkholz-2
In reply to this post by Ciaran McCreesh-4
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
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Michael Haubenwallner-3
In reply to this post by Ciaran McCreesh-4

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

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: 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

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

"Mateusz A. Mierzwiński"
In reply to this post by Donnie Berkholz-2
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.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Ciaran McCreesh-4
On Wed, 16 Apr 2008 09:52:13 +0200
"Mateusz A. Mierzwin'ski" <[hidden email]> 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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

"Mateusz A. Mierzwiński"
In reply to this post by Donnie Berkholz-2
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".
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Bo Ørsted Andresen-2
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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Ciaran McCreesh-4
In reply to this post by "Mateusz A. Mierzwiński"
On Wed, 16 Apr 2008 09:56:04 +0200
"Mateusz A. Mierzwiński" <[hidden email]> 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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

"Mateusz A. Mierzwiński"
In reply to this post by Bo Ørsted Andresen-2
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.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

"Mateusz A. Mierzwiński"
In reply to this post by Ciaran McCreesh-4
Ciaran McCreesh pisze:

> On Wed, 16 Apr 2008 09:56:04 +0200
> "Mateusz A. Mierzwiński" <[hidden email]> 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"?


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Markus Rothe-2
"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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Bo Ørsted Andresen-2
In reply to this post by "Mateusz A. Mierzwiński"
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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Ulrich Mueller-2
In reply to this post by Ciaran McCreesh-4
>>>>> 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
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Ciaran McCreesh-4
On Wed, 16 Apr 2008 10:40:49 +0200
Ulrich Mueller <[hidden email]> 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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

"Mateusz A. Mierzwiński"
In reply to this post by Markus Rothe-2
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...
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: What are blocks used for?

Ciaran McCreesh-4
On Wed, 16 Apr 2008 11:07:20 +0200
"Mateusz A. Mierzwiński" <[hidden email]> 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

signature.asc (196 bytes) Download Attachment
123