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

[Ciaran McCreesh]

On Wed, 16 Apr 2008 07:54:48 +0200
"Mateusz A. Mierzwin'ski" <[EMAIL PROTECTED]> 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
Description: PGP signature

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

[gentoo-dev] What are blocks used for?

[Ciaran McCreesh]

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
Description: PGP signature

[gentoo-dev] adding OpenRC to emerge --info output

[Doug Goldstein]

All,

I'll be adding sys-apps/openrc to info_pkgs in the profiles.

That's all.

--
Doug Goldstein <[EMAIL PROTECTED]>
http://dev.gentoo.org/~cardoe/
--
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Early stabilisation

[Jeroen Roovers]

 Dear ebuild maintainers,


thirty days is the norm for the minimal period between an ebuilds last
non-keywording change while in the tree and the usual call for
stabilisation. If you cannot find a pressing reason to push
stabilisation forward, then don't ask. In the last few days I have seen
several early calls for stabilisation (bugs #217148, #217845, #217841
and #217839 for instance) where no adequate reason was given, in my
opinion.

A good reason might be an important fix of a severe bug, a fix for a
build problem that couldn't be applied to a stable version but had to
go into an ebuild revision, or a version/revision that fixes a security
problem.

On the other hand, maybe these early stabilisation bug reports are a
sign of the times and we need to shorten the normal thirty day period,
become even more of a cutting edge distro - or at least discuss the
options.


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

Re: [gentoo-dev] escaping variables in sed expressions

[Mike Frysinger]

On Tuesday 15 April 2008, Marijn Schouten (hkBst) wrote:
> Hi list,
>
> it seems I have been using some fragile sed expression and I'd like to tap
> the collective wisdom for avoiding doing that in the future.
>
> dev-scheme/slib-3.1.5-r1 currently does
>
> sed "s_prefix = /usr/local/_prefix = ${D}/usr/_" -i Makefile

ignoring the escape character (which is currently standardized in the tree as 
a colon), expressions like this are inherently fragile due to makefile 
changes.  i tend to do:
sed -i '/^prefix[[:space:]]*=/s:=.*:=/usr' Makefile
-mike


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

Re: [gentoo-dev] escaping variables in sed expressions

[Marius Mauch]

On Tue, 15 Apr 2008 16:17:54 +0200
Frank Gruellich <[EMAIL PROTECTED]> wrote:

> * Santiago M. Mola <[EMAIL PROTECTED]> 15. Apr 08:
> > On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
> > Currently is use ':' as sed delimiter when paths are involved. I'd
> > also like to hear from you about proper delimiters if you think ':'
> > is not safe enough.
> > 
> > AFAIK, the only corner case which would make this fail would be
> > Windows paths (C:/gentoo-prefix).
> 
> Even though it's probably stupid to use it, but ':' is a valid
> character within a path.  I've no solution for this problem, however.

Valid maybe (but then pretty much every character is valid), but colon
is used as path delimiter in many other contexts (e.g. $PATH) so it's
rather unlikely to be used.

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

Re: [gentoo-dev] escaping variables in sed expressions

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petteri Räty wrote:
| You should just fix the Makefile to respect DESTDIR and send the patch
| upstream.

You're right of course, but that is only the right way for this specific 
instance and not
a general way of handling tricky sed expressions.

Marijn

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

iEYEARECAAYFAkgEyckACgkQp/VmCx0OL2z7+QCdHx8n7Py3CQJy1tJMmYkyCmJW
yUgAoIVlu60bCfPJqC1iNIYc8AegKrCm
=1ItB
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] escaping variables in sed expressions

[Petteri Räty]

Marijn Schouten (hkBst) kirjoitti:

Hi list,

it seems I have been using some fragile sed expression and I'd like to 
tap the collective

wisdom for avoiding doing that in the future.

dev-scheme/slib-3.1.5-r1 currently does

sed "s_prefix = /usr/local/_prefix = ${D}/usr/_" -i Makefile

to make it not violate the sandbox. However a user had set
PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to 
contain too may

underscores and failing.[1]

There are several option to handle this. I could use a less common 
delimiter or I could
escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that 
doesn't suffer

from this problem (thanks to dleverton):

sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile

Comments?

Marijn

[1]: http://bugs.gentoo.org/show_bug.cgi?id=217735



You should just fix the Makefile to respect DESTDIR and send the patch 
upstream.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] escaping variables in sed expressions

[Frank Gruellich]

* Santiago M. Mola <[EMAIL PROTECTED]> 15. Apr 08:
> On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
> Currently is use ':' as sed delimiter when paths are involved. I'd
> also like to hear from you about proper delimiters if you think ':' is
> not safe enough.
> 
> AFAIK, the only corner case which would make this fail would be
> Windows paths (C:/gentoo-prefix).

Even though it's probably stupid to use it, but ':' is a valid character
within a path.  I've no solution for this problem, however.

Kind regards,
 Frank.
-- 
Sigmentation fault
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] escaping variables in sed expressions

[Ulrich Mueller]

> On Tue, 15 Apr 2008, Marijn Schouten (hkBst) wrote:

> There are several option to handle this. I could use a less common
> delimiter or I could escape it: ${D//_/\_} instead of ${D}. I could
> use a sed expression that doesn't suffer from this problem (thanks
> to dleverton):

> sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile

Hi Marijn,

both approaches won't work since you would have to escape not only the
pattern delimiter, but also sed special characters (like "\" and "&")
_and_ make special characters (e.g. the dollar sign).

Probably better to pass it to make via a command argument or
environment variable.

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

Re: [gentoo-dev] escaping variables in sed expressions

[David Leverton]

On Tuesday 15 April 2008 12:14:57 Marijn Schouten (hkBst) wrote:
> There are several option to handle this. I could use a less common
> delimiter or I could escape it: ${D//_/\_} instead of ${D}. I could use a
> sed expression that doesn't suffer from this problem (thanks to dleverton):
>
> sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile

Just to clarify, I didn't think of escaping when I suggested this.  Escaping 
is probably cleaner, and certainly easier to understand.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] escaping variables in sed expressions

[Fabian Groffen]

On 15-04-2008 13:05:26 +0200, Santiago M. Mola wrote:
> On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
> <[EMAIL PROTECTED]> wrote:
> >
> >  Hi list,
> >
> >  it seems I have been using some fragile sed expression and I'd like to tap
> > the collective
> >  wisdom for avoiding doing that in the future.
> >
> >  dev-scheme/slib-3.1.5-r1 currently does
> >
> >  sed "s_prefix = /usr/local/_prefix = ${D}/usr/_" -i Makefile
> >
> >  to make it not violate the sandbox. However a user had set
> >  PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to
> > contain too may
> >  underscores and failing.[1]
> >
> >  There are several option to handle this. I could use a less common
> > delimiter or I could
> >  escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that
> > doesn't suffer
> >  from this problem (thanks to dleverton):
> >
> >  sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile
> >
> >  Comments?
> >
> 
> Currently is use ':' as sed delimiter when paths are involved. I'd
> also like to hear from you about proper delimiters if you think ':' is
> not safe enough.

I met one case where : was indeed a problem, but that was in
CFLAGS/LDFLAGS replacements.  Some linkers accept (and do require)
arguments that are like "-mg:2512s".

> AFAIK, the only corner case which would make this fail would be
> Windows paths (C:/gentoo-prefix).

C:\ iirc, but Cygwin seems to map this as /cygdrive/C, Interix as
/dev/fs/C, command prompt I have no clue how portage could ever normally
work there.  SpikeSource's SpikeWAMP uses Cygwin underneath, so
Portage/ebuilds will see the mapped paths only, never heard of any
problems from them regarding this either.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] escaping variables in sed expressions

[Santiago M. Mola]

On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
<[EMAIL PROTECTED]> wrote:
>
>  Hi list,
>
>  it seems I have been using some fragile sed expression and I'd like to tap
> the collective
>  wisdom for avoiding doing that in the future.
>
>  dev-scheme/slib-3.1.5-r1 currently does
>
>  sed "s_prefix = /usr/local/_prefix = ${D}/usr/_" -i Makefile
>
>  to make it not violate the sandbox. However a user had set
>  PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to
> contain too may
>  underscores and failing.[1]
>
>  There are several option to handle this. I could use a less common
> delimiter or I could
>  escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that
> doesn't suffer
>  from this problem (thanks to dleverton):
>
>  sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile
>
>  Comments?
>

Currently is use ':' as sed delimiter when paths are involved. I'd
also like to hear from you about proper delimiters if you think ':' is
not safe enough.

AFAIK, the only corner case which would make this fail would be
Windows paths (C:/gentoo-prefix).

Regards,

-- 
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] escaping variables in sed expressions

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi list,

it seems I have been using some fragile sed expression and I'd like to tap the 
collective
wisdom for avoiding doing that in the future.

dev-scheme/slib-3.1.5-r1 currently does

sed "s_prefix = /usr/local/_prefix = ${D}/usr/_" -i Makefile

to make it not violate the sandbox. However a user had set
PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to contain 
too may
underscores and failing.[1]

There are several option to handle this. I could use a less common delimiter or 
I could
escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that 
doesn't suffer
from this problem (thanks to dleverton):

sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile

Comments?

Marijn

[1]: http://bugs.gentoo.org/show_bug.cgi?id=217735

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

iEYEARECAAYFAkgEjjEACgkQp/VmCx0OL2zGDQCcCcgx1/g/UXpB38HIjKjNhmL6
S4MAoK1aXJS6SW9FaZT4i2iaeo6AlD2u
=Id31
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list