Re: [gentoo-dev] What are blocks used for?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | 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 | 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?
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?
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?
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?
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?
On Wed, 16 Apr 2008 09:52:13 +0200 Mateusz A. Mierzwin'ski [EMAIL PROTECTED] 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 Description: PGP signature
Re: [gentoo-dev] What are blocks used for?
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
[gentoo-dev] PostgreSQL Status
Since my blog doesn't get syndicated on planet.gentoo.org I'm posting the
entry here again, but it's probably a good idea anyway:
First I want to apologize for the current situation. I know we're lagging
behind and I know that bugs are piling up.
As a small excuse I can only say that my time is limited and PostgreSQL
isn't the only thing in Gentoo I (have to) maintain.
But there are good news:
Thanks to the help of Michael Krelin (also known as polyonymous on IRC) I
was able to commit a whole new set of ebuilds yesterday.
Now, you're probably going to ask why we just didn't go on with the current
ebuilds in the tree.
There are a couple of reasons:
a) dev-db/libpq is slotted but with collisions. Fixing this wasn't really an
option since slotting this was wrong from the beginning.
b) The split-up in two packages dev-db/{libpq,postgresql} was wrong too:
There are a couple of packages which do not only need libpq, but also one
of the other PostgreSQL libraries (like libecpg, libpgtypes, libecpg_compat
or libpgport).
c) Upgrading between major versions of PostgreSQL requires the DB admin to
bump the database using the old version, moving the database away and to
reload the dump into a new database cluster using the new version of
PostgreSQL. Having to take down the old server and purging the old version
of PostgreSQL before being able to try out the new one is more than
cumbersome. Therefore a slotted postgresql-server is needed to make the
upgrade easier.
d) A lot of things were broken in the old postgresql ebuilds as you can see
when going through the bug list and we needed to give them a general
overhaul.
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that
splitting up packages isn't the Gentoo way. I know we could have done it
using USE flags but this approach gives more flexibility due to the current
way how binary packages are being generated and distributed.
b) New virtuals: virtual/postgresql-{base,server} to be able to install
pgcluster as your postgresql-base in a next step.
c) Slotting: It is now possible to have more than one major version of
PostgreSQL installed and running on the same machine.
d) A lot of other improvements, in detail, the following bugs will be fixed:
42894 Suggestion of use of slots for PostgreSQL
49864 dev-db/postgresql - pkg_config should allow passing optio...
55073 PostgreSQL client versus server installation
154620 PostgreSQL 8.1 server lacks instrumentation functions for...
158509 dev-db/libpq-8.0.9 fails configure with segmentation faul...
159223 postgresql threads USE flag required for ecpg
160178 dev-db/libpq : using (almost deprecated) gnuconfig_update
160181 dev-db/postgresql : using (almost deprecated) gnuconfig_u...
161803 dev-db/postgresql - /etc/conf.d/postgresql PG_OPTS variab...
161980 QA Notice: USE Flag 'kernel_linux' not in IUSE for dev-db...
177555 Postgresql/libpg upgrade from 8.1.8 to libpg-8.2.4 and po...
194350 =dev-db/libpq-8.2.4 creates broken symlinks
194701 dev-db/postgresql - wrong elog into about configuration f...
198434 dev-db/postgresql - add ldap use flag
206725 dev-db/{libpq,postgresql} 8.2.7/8.3.1 version bump
206820 dev-db/postgresql default conf.d should not override max_...
209826 dev-db/postgresql - 2 issues with the current init script
210938 dev-db/postgresql - disable strict permission check on ss...
213699 dev-db/libpq-8.2.6 failed to configure w/ USE=threads
214438 The dev-db/postgresql-8.2.6 ebuild does not respect confi...
215940 dev-db/postgresql provides bad init script for baselayout...
What you have to do to switch:
I'll put together more documentation as soon as the ebuilds get unmasked (in
1-2 weeks).
In general the only thing you have to then do is to uninstall dev-db/libpq
and dev-db/postgresql and install the same version of postgresql-base and
postgresql-server. No revdep-rebuild is needed.
For early adopters: It's best to wait until we changed the dependencies,
afterwards you can unmask the dev-db/postgresql-{docs,base,server}
packages...
What is needed from the ebuild developers side:
We have to change every dependency on dev-db/libpq to
virtual/postgresql-base and dev-db/postgresql to virtual/postgresql-server.
As soon as the old ebuilds are gone, we have to go through the ebuilds
depending on virtual/postgresql-server whether they can be built with
dev-db/postgresql-base only. Do not switch from dev-db/postgresql to
virtual/postgresql-base directly as long as you can't assure that your
package builds with libpq only.
Well, that's it basically. Don't hesitate to contact me in case of problems
or suggestions. You can answer to this post, leave comments on
http://dev-zero.ch/blog/ or send me a mail of course :-).
(But don't expect me to read forum entries since I simply do not have the
time to do that regularly.)
Again, many thanks to Michael Krelin and all the others who helped with
testing and sending patches.
Cheers,
Tiziano
--
gentoo-dev@lists.gentoo.org
Re: [gentoo-dev] What are blocks used for?
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 Description: This is a digitally signed message part.
Re: [gentoo-dev] What are blocks used for?
On Wed, 16 Apr 2008 09:56:04 +0200 Mateusz A. Mierzwiński [EMAIL PROTECTED] 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 Description: PGP signature
Re: [gentoo-dev] What are blocks used for?
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?
Ciaran McCreesh pisze: On Wed, 16 Apr 2008 09:56:04 +0200 Mateusz A. Mierzwiński [EMAIL PROTECTED] 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?
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 pgpx9xdd2wOeP.pgp Description: PGP signature
Re: [gentoo-dev] PostgreSQL Status
On 09:55 Wed 16 Apr , Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that
splitting up packages isn't the Gentoo way. I know we could have done it
using USE flags but this approach gives more flexibility due to the current
way how binary packages are being generated and distributed.
I'd like to hear some more info on this point.
In general the only thing you have to then do is to uninstall dev-db/libpq
and dev-db/postgresql and install the same version of postgresql-base and
postgresql-server. No revdep-rebuild is needed.
For early adopters: It's best to wait until we changed the dependencies,
afterwards you can unmask the dev-db/postgresql-{docs,base,server}
packages...
People want `emerge postgresql` to do something. Otherwise it's not
always obvious which random hyphenated packages you're supposed to
install, and it's just like you're digging around some huge subpackage
list in Ubuntu or Fedora.
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
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 Description: This is a digitally signed message part.
[gentoo-dev] Re: PostgreSQL Status
Donnie Berkholz wrote:
On 09:55 Wed 16 Apr , Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that
splitting up packages isn't the Gentoo way. I know we could have done it
using USE flags but this approach gives more flexibility due to the
current way how binary packages are being generated and distributed.
I'd like to hear some more info on this point.
Consider this use case:
30 machines with one staging machine and binary deployment.
On 28 machines you want the libraries only, on one you also need the server
and on one you want the docs.
Easy done with (sanely) splitted packages.
Please note that the only additional package compared to the split
dev-db/{libpq,postgresql} is dev-db/postgresql-docs.
In general the only thing you have to then do is to uninstall
dev-db/libpq and dev-db/postgresql and install the same version of
postgresql-base and postgresql-server. No revdep-rebuild is needed.
For early adopters: It's best to wait until we changed the dependencies,
afterwards you can unmask the dev-db/postgresql-{docs,base,server}
packages...
People want `emerge postgresql` to do something. Otherwise it's not
always obvious which random hyphenated packages you're supposed to
install, and it's just like you're digging around some huge subpackage
list in Ubuntu or Fedora.
Well, we can re-introduce a virtual/postgresql (or dev-db/postgresql) after
the old ebuilds are gone.
Cheers,
Tiziano
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What are blocks used for?
On Wed, 16 Apr 2008 11:07:20 +0200 Mateusz A. Mierzwiński [EMAIL PROTECTED] 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 Description: PGP signature
Re: [gentoo-dev] Early stabilisation
Jeroen Roovers wrote: 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. Given that 3 of the 4 are from one person, I wouldn't draw broad conclusion from this. 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. I'd say leave the current norm and smack the misbehaving maintainers :) Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
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?
Mateusz A. Mierzwin'ski [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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?
Mateusz A. Mierzwiński [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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?
Duncan pisze: Mateusz A. Mierzwiński [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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?
-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?
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
[gentoo-dev] Re: PostgreSQL Status
Carsten Lohrke wrote: c) Upgrading between major versions of PostgreSQL requires the DB admin to bump the database using the old version, moving the database away and to reload the dump into a new database cluster using the new version of PostgreSQL. Having to take down the old server and purging the old version of PostgreSQL before being able to try out the new one is more than cumbersome. Therefore a slotted postgresql-server is needed to make the upgrade easier. As I read upstream's documentation¹, this is incorrect: # It is recommended that you use the pg_dump and pg_dumpall programs from # the newer version of PostgreSQL, to take advantage of any enhancements # that may have been made in these programs. Current releases of the dump # programs can read data from any server version back to 7.0. While the dump command can read clusters created by an older version it is still necessary to dump and reload your data on version bumps between major versions as written in http://www.postgresql.org/docs/8.3/static/install-upgrading.html: [...] The internal data storage format typically changes in every major release of PostgreSQL. Therefore, if you are upgrading an existing installation that does not have a version number of 8.3.x, you must back up and restore your data. If you are upgrading from PostgreSQL 8.3.x, the new version can use your current data files so you should skip the backup and restore steps below because they are unnecessary. [...] Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: What are blocks used for?
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?
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?
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] escaping variables in sed expressions
On Wed, 16 Apr 2008 19:17:51 +0200 Frank Gruellich [EMAIL PROTECTED] wrote: I was not able to create a filename or path containing it. (Anyone else?) Unix file names can't contain / or null. Unfortunately that stupid sed does not work with \x00 as delimiter... Nor do most Unix apps, since they tend to be written in C using all those C library functions that work on null terminated strings. Null introduces far more problems than it solves, character-wise... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] escaping variables in sed expressions
* Marius Mauch [EMAIL PROTECTED] 15. Apr 08:
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.
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),
I've been a bigmouth so I couldn't sleep last night thinking about that
problem (which in fact happened to me sometimes). The very last
character I'd expect in a path would be the NUL char (\x00). I was not
able to create a filename or path containing it. (Anyone else?)
Unfortunately that stupid sed does not work with \x00 as delimiter...
But because a path will not contain a \x00 you can replace all
$delimiter_of_your_dreams with a \x00 and later change it back to the
original without adding any new.
Looks like:
(0) [EMAIL PROTECTED] [~] % echo '/foo/bar/foo:baz/baz bar/laber_rabarber/' |tr
'/' '\0' |sed 's/a/o/g' |tr '\0' '/'
/foo/bor/foo:boz/boz bor/lober_roborber/
(0) [EMAIL PROTECTED] [~] %
Moving that to OP's problem he could maybe use something like:
tr '/' '\0' Makefile |sed s_prefix = /usr/local/_prefix = ${D}/usr/_ |tr
'\0' '/' Makefile.new
This obviously introduces the problem that a Makefile contains more than
just paths and there could be a \x00 somewhere... but... well...
but colon is used as path delimiter in many other contexts (e.g.
$PATH) so it's rather unlikely to be used.
I'm *very* paranoid. ;-)
Kind regards,
Frank.
--
Sigmentation fault
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Early stabilisation
On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote: thirty days is the norm for the minimal period between an ebuilds last It is the norm. It is not a requirement. In fact, it is specifically a guideline rather than a hard rule. It is up to the maintainer's discretion when to ask for stabilization, just like it is up to the arch team's discretion when to actually *do* the stabilization. If you don't think that it's ready on your arch, say so, but be prepared to defend why you think so when the package maintainer, who should be much more familiar with the package, thinks that it is ready. 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. I'd say leave the current norm and smack the misbehaving maintainers :) Who says that they're misbehaving? Again, the maintainers probably know their packages better than anyone else, so why are we not trusting their judgement again? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Early stabilisation
Wed, 16 Apr 2008 12:09:24 -0700 Chris Gianelloni [EMAIL PROTECTED] kirjoitti: On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote: thirty days is the norm for the minimal period between an ebuilds last It is the norm. It is not a requirement. In fact, it is specifically a guideline rather than a hard rule. It is up to the maintainer's discretion when to ask for stabilization, just like it is up to the arch team's discretion when to actually *do* the stabilization. If you don't think that it's ready on your arch, say so, but be prepared to defend why you think so when the package maintainer, who should be much more familiar with the package, thinks that it is ready. 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. I'd say leave the current norm and smack the misbehaving maintainers :) Who says that they're misbehaving? Again, the maintainers probably know their packages better than anyone else, so why are we not trusting their judgement again? Thanks for this, I was going to reply in similar fashion but didn't want to (accidentally) start flaming.. - drac -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: What are blocks used for?
On Wed, 16 Apr 2008 18:59:26 +0200 Mateusz A. Mierzwiński [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
[gentoo-dev] Re: escaping variables in sed expressions
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 16 Apr 2008 18:24:05 +0100: On Wed, 16 Apr 2008 19:17:51 +0200 Frank Gruellich [EMAIL PROTECTED] wrote: I was not able to create a filename or path containing it. (Anyone else?) Unix file names can't contain / or null. Feel free to correct me if I'm mistaken, but I believe I was reading somewhere and /thought/ it was this list... While you are almost certainly correct on POSIX/Unix filenames and the shell won't accept / in a filename, IIRC (from reading) it's often possible for C programs to code a literal / in a filename, and possible for some filesystems (also written in C, generally) to accept it. Thus, while POSIX/Unix standards don't allow it, in practice, it's sometimes possible, if rare. This was an entirely new idea to me when I read it, but it sounded like just the sort of filesystem implementation detail one might overlook, so I remembered it, I /believe/ accurately. Whatever your faults, you /do/ tend to be quite accurate on such things, so if you'd either confirm this or disabuse me of my misinformation, I'd definitely appreciate it. If it's correct, it's certainly worth considering before one starts making absolutist assumptions and statements that could be wrong in some cases, particularly as such bad assumptions seem to often lead ultimately to security faults. -- 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: escaping variables in sed expressions
Duncan a écrit : Whatever your faults, you /do/ tend to be quite accurate on such things. Wow, you've managed to turn a nice technical discussion (which is rare enough in recent history) into a let's-start-bashing-people thread. You've lost all credibility in just one sentence... Pity. If it's correct, it's certainly worth considering before one starts making absolutist assumptions and statements that could be wrong in some cases, particularly as such bad assumptions seem to often lead ultimately to security faults. Well gee, thanks for considering Gentoo security, I feel so much better now. Seriously though, please leave the condescending tone of your post at the door. This post of yours is seriously out of line (imho). Thanks Rémi -- gentoo-dev@lists.gentoo.org mailing list
