Re: [gentoo-dev] Early stabilisation
Samuli Suominen wrote: 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. Okay. So we can just agree it's better if the maintainer tells his reasons when opening the bug, to spare the later clarifications? 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.. Sorry I used a harsh word myself, didn't want to flame neither. Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}.
WRONG we aren't debian.
we have a nice use for documentation...
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.
It gives an annoyance please reconsider.
b) New virtuals: virtual/postgresql-{base,server} to be able to install
pgcluster as your postgresql-base in a next step.
see before.
c) Slotting: It is now possible to have more than one major version of
PostgreSQL installed and running on the same machine.
Great =)
d) A lot of other improvements, in detail, the following bugs will be fixed:
Wonderful =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: escaping variables in sed expressions
On Thu, Apr 17, 2008 at 6:31 AM, Duncan [EMAIL PROTECTED] wrote: 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. If that's possible, we shouldn't support it anyway. If someone wants to use /var/tmp/port\/age we'll just stab him, if someone releases a tarball with such filenames we'll stab him, too. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
* Tiziano Müller [EMAIL PROTECTED] schrieb:
Hi,
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:
Actually, I'd clearly prefer lists like this one for those discussions.
Blogs are okay for writing journal articles and let people comment them,
but bad for real discussions, IMHO.
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.
Well, my time is limited too (hmm, an contract for Gentoo development
would be fine ;-)), otherwise I'd already reworked the pg ebuilds ;-o
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.
ACK. It should be done by *real* MVCC. But I doubt that portage is
actually capable of this yet. For the vast majority of the cases I
see slots just as a dirty hack ;-p
The main problem for MVCC (and also what often makes revdep-rebuild
necessary) is the point that source and binary packages have to be
completely different: the mapping from source to binary happens at
only build time and all the rest of the dependency handling derives
from that. I'm currently implementing this approach in my own build/
packaging system, but it's going to tricky.
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).
NAK! Each of these libraries are their own entities. Some clients even may
depend on one of them, but not libpq. So they clearly belong to their
own packages.
I do *NOT* want *ANY* unneeded stuff in my systems. You'll force me to fork.
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.
That's the point where we need *real* MVCC. An virtual package could
coordinate the update process (eg. pulling in new versions and providing
update utils, maybe with some additional refcounting and automatic cleanup
based on that)
Yes, MVCC is not trivial ;-P
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 actually think packages should be split whenever suitable, useflags should
only be used for *conditional* building (where features are switched that
do *not* reflect separate modules) or for virtual (frontend) packages.
b) New virtuals: virtual/postgresql-{base,server} to be able to install
pgcluster as your postgresql-base in a next step.
Yes, frontend virtuals for convenience are an good idea for many users.
I, personally, probably won't use them, since my setups would be too
complex for them. Other folks with simpler setups might be perfectly
fine with them.
c) Slotting: It is now possible to have more than one major version of
PostgreSQL installed and running on the same machine.
Great. This makes smooth update processes easier (reduces the need of
custom ebuilds). But I, pesonally, prefer *separate* packages instead
of slots.
159223 postgresql threads USE flag required for ecpg
BTW: does portage meanwhile handle feature dependencies ?
It's always a big mess when an whole install/update fails in the middle
just because some package wants some other built with certain useflag :(
161980 QA Notice: USE Flag 'kernel_linux' not in IUSE for dev-db...
Naive question: why does this useflag appear in pg ?
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
-
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Wednesday, 16 of April 2008 11:07:20 Mateusz A. Mierzwiński wrote: Markus Rothe pisze: Mateusz A. Mierzwiński wrote: Yes, You have right but I have thinking about something like OPTION for emerge or switch to enable that function. Emerge could provide two options of working - with replace and with sending error. Maybe switch like --force-install? This is not a thread about a specific implementation of PMS. This thread is about adding specs to PMS that allow implementations (i.e. paludis or portage etc.) to do it right. -markus Yeah! Right... You know what? I think that this thread is about making Gentoo unstable, unusable and user non-friendly. Bad things are happend in Gentoo and I freezing distfiles and gentoo stages on my disk. Destroy that distro as much as You can. See yourself at DistroWatch what place have Gentoo today? Couple months ago it was 7-th place, and now? People are escaping from Gentoo - tell me Why? Maybe because bad programing practices and adding something that is not needed, and most needed things are sent back to archive of sick people complains? Try to hear others, not only Your pride... Cześć Mateusz. Myślę, że źle rozumiesz założenia pomysłu, który został zaproponowany przez Ciarana. Zrozum, że chodzi o to, żeby menadżer pakietów potrafił rozwiązywać problemy pakietów wzajemnie się blokujących i podawał użytkownikowi informację dlaczego taki blok istnieje i jak się go pozbyć. Nie twierdzę, że nie masz racji, nie twierdzę też, że ją masz. Ale patrząc na cały temat jesteś jedyną osobą, która twardo się przeciwstawia pomysłowi nie podając żadnych argumentów. Ponadto, bez obrazy, ale poziom Twojego języka nie jest być może na tyle dobry, żeby inni Cię mogli zrozumieć (robisz błędy gramatyczne itp.). Postaraj się przeczytać tę dyskusję ponownie i zrozumieć założenie pomysłu. Tu [1] masz adres do archiwum. [1] - http://archives.gentoo.org/gentoo-dev/msg_e7f929ecc22ca5bf67fc80e78e5aaa16.xml -- Cheers Dawid Węgliński signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PostgreSQL Status
* Luca Barbato [EMAIL PROTECTED] schrieb:
Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}.
WRONG we aren't debian.
It's bad, just because Debian does it ?!
Sounds quite religions to me. I don't like religions interfering with
technical designs.
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
-
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: PostgreSQL Status
* Tiziano Müller [EMAIL PROTECTED] schrieb: WRONG we aren't debian. This is why we decided not to split out headers, clients and contrib. Actually, I'd like to see them all split out. But this sooner or later requires the upstream (or an intermediate layer, like OSS-QM) to support this - individual distros shouldn't do this by themselves (too much unnecessary duplicate work). cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
On Thu, Apr 17, 2008 at 10:10 PM, Enrico Weigelt [EMAIL PROTECTED] wrote:
* Luca Barbato [EMAIL PROTECTED] schrieb:
Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}.
WRONG we aren't debian.
It's bad, just because Debian does it ?!
Yes, because their technical design is different from Gentoo's.
Debian/$binary_distro have to split up packages because they have no
other way of mapping configure flags to what the user wants to
install. Gentoo does, and they're called USE flags.
Sounds quite religions to me. I don't like religions interfering with
technical designs.
See above.
--
~Nirbheek Chauhan
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: PostgreSQL Status
* Tiziano Müller [EMAIL PROTECTED] schrieb: 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 That's the point where MVCC is needed, at least for critical applications and large databases: each db has to be tested carefully on the new server before moving to production and downtimes have to be minmal. An single-version system cannot provide this. I'm doing this by assigning multiple sockets to the server (one per DB) and so migrating the DB's one by one w/o having to touch the clients. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
* Nirbheek Chauhan [EMAIL PROTECTED] schrieb: It's bad, just because Debian does it ?! Yes, because their technical design is different from Gentoo's. Still too religious ;-P Would be different if you'd said we don't need to split since we have useflags or we want to stay as near to upstream as possible instead of we're not debian. Being different, just to be different is really too pubertal for me ;-o Debian/$binary_distro have to split up packages because they have no other way of mapping configure flags to what the user wants to install. Gentoo does, and they're called USE flags. Right, binary distros have a much bigger presure on that, but this doesn't mean that splitting is always bad. Think of all these useflag-deps, which often wouldn't be necessary if the packages would be split in finer granularity. Of course, this is mostly the upstream's fault. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Linux 2.6.25 info
2.6.25 was released today, gentoo-sources-2.6.25 is now in portage. As usual this will break some packages in the portage tree (ones that include kernel code), the tracker for such issues is here: http://bugs.gentoo.org/show_bug.cgi?id=218127 Jakub normally does a wonderful job of herding all such bugs, but it looks like he isn't around at the moment. Please help out by adding your bugs there, assuming that your package is in the stable tree and the current stable one works on 2.6.24. As usual I hope to start thinking about 2.6.25 stabling in 3 weeks time (that'll be May 8th) but this is of course subject to the state of affairs when we get that far :) Daniel -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
On Thu, Apr 17, 2008 at 10:37 PM, Enrico Weigelt [EMAIL PROTECTED] wrote:
* Nirbheek Chauhan [EMAIL PROTECTED] schrieb:
It's bad, just because Debian does it ?!
Yes, because their technical design is different from Gentoo's.
Still too religious ;-P
Of course, that's your opinion to have and keep.
Would be different if you'd said we don't need to split since we
have useflags or we want to stay as near to upstream as possible
instead of we're not debian. Being different, just to be
different is really too pubertal for me ;-o
The person you were replying to is a Gentoo Council member, elected by
the very devs that run Gentoo. I believe one should try and look
deeper in the meaning of such a man's words before labelling them as
pubertal.
The words of a veteran usually aren't written in blind emotion or with
prejudice.
Debian/$binary_distro have to split up packages because they have no
other way of mapping configure flags to what the user wants to
install. Gentoo does, and they're called USE flags.
Right, binary distros have a much bigger presure on that, but this
doesn't mean that splitting is always bad.
There are specific use-cases where splitting is good, such as with
gstreamer, gtk-sharp, gnome-python{,-desktop,-extras} which are
essentially dependencies of other packages, and where built_with_use
checks are horrid to use.
Think of all these useflag-deps, which often wouldn't be necessary
if the packages would be split in finer granularity.
Of course, this is mostly the upstream's fault.
I personally have no opinion about the -base and -server split, since
I do not know enough about it. But I am firmly against the -docs split
since the doc USE flag is for this use-case, and I see no reason why
not to use it.
Just stick a USE=doc on -base and be done with it
--
~Nirbheek Chauhan
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Early stabilisation
On Thu, 17 Apr 2008 15:33:17 +0300 Samuli Suominen [EMAIL PROTECTED] wrote: Thu, 17 Apr 2008 09:43:59 +0200 Vlastimil Babka [EMAIL PROTECTED] kirjoitti: Okay. So we can just agree it's better if the maintainer tells his reasons when opening the bug, to spare the later clarifications? It works. Do it. Then it will work just as well after a few more weeks. :) Kind regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Early stabilisation
On Thu, 17 Apr 2008 15:33:17 +0300 Samuli Suominen [EMAIL PROTECTED] wrote: It works. Do it. Oh by the way. This isn't directed toward you personally, but I personally detest this do it attitude. You wouldn't say that to my face, would you? (Trust me, you would regret it.) :) JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
* Nirbheek Chauhan [EMAIL PROTECTED] schrieb:
Would be different if you'd said we don't need to split since we
have useflags or we want to stay as near to upstream as possible
instead of we're not debian. Being different, just to be
different is really too pubertal for me ;-o
The person you were replying to is a Gentoo Council member, elected by
the very devs that run Gentoo. I believe one should try and look
deeper in the meaning of such a man's words before labelling them as
pubertal.
Well, this is my personal feeling, and this is totally independent from
his position.
I've just got headaches with this we're not debian argumentation.
Surely there are technical reasons to do certain things different than
other distros, and so we should talk about exactly about these points.
(problem - analyis - solution).
Just insisting on being different isn't a technical reason, just an
pubertal behaviour (well, there are good reasons for this behaviour in
that that age, eg. becoming independent from the parent generation).
This reminds me on the anti-fascist folks here in Germany, who tend to
define themselves on being against fascists and declaring everyone with
different opponions to be one (note that Germany never had noticable fascist
movements - we had national socialists, but that's very different ;-O)
The words of a veteran usually aren't written in blind emotion or with
prejudice.
Might be. But in this case, I really feel different.
Please let's talk about concepts and practises of other distros objectively,
leaving out personal antipathies. Every one has different views and needs,
and technical decisions should derive them them, not from personal taste.
So for example the splitting issue has to be decided for each package.
As we're currently talking about PostgreSQL, we have to look at the
possible ways to do (or not to do) so with it and weight the pros and
cons of the different options.
This decision process should be individual to each package - there is
no (good) universal answer. If you try to declare an universal answer
to everyone, you get religious ;-P
Right, binary distros have a much bigger presure on that, but this
doesn't mean that splitting is always bad.
There are specific use-cases where splitting is good, such as with
gstreamer, gtk-sharp, gnome-python{,-desktop,-extras} which are
essentially dependencies of other packages, and where built_with_use
checks are horrid to use.
Yes, and there a lots of them.
Classical example: language bindings for certain libs. They really
should be different packages. But, of course, the fault mostly comes
from the upstream and individual distros aren't the right place to
fix this (again, one of the reasons why I founded the OSS-QM project).
I personally have no opinion about the -base and -server split, since
I do not know enough about it. But I am firmly against the -docs split
since the doc USE flag is for this use-case, and I see no reason why
not to use it.
Historically, the manuals (actually, electronic books - printed out
about 1k pages) have been an separate package from upstream. And this
for a good reason: they an different entitiy (even maintained by
different people), quite large and (un)related to the rest of PQ just
like an programming book to an invidiual compiler (note that it's also
contains of the most complete posix-SQL references in the OSS world).
Just stick a USE=doc on -base and be done with it
This has an major drawback: requires to do an complete rebuild/reinstall
of the whole package if you just need the manual. When setting up an
new server, you normally don't need the complete manual installed
(assuming you're already confident w/ PQ), but you need it someday
later when you have to look up something and other media (web access
or printed out) are not convenient/available.
I, personally, don't *need* it at all, but having an separate package
makes it more convenient. And I don't see any reasons against that
split as long as people are willing to maintain it.
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
-
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
On Fri, Apr 18, 2008 at 12:17 AM, Enrico Weigelt [EMAIL PROTECTED] wrote: * Nirbheek Chauhan [EMAIL PROTECTED] schrieb: I personally have no opinion about the -base and -server split, since I do not know enough about it. But I am firmly against the -docs split since the doc USE flag is for this use-case, and I see no reason why not to use it. Historically, the manuals (actually, electronic books - printed out about 1k pages) have been an separate package from upstream. And this for a good reason: they an different entitiy (even maintained by different people), quite large and (un)related to the rest of PQ just like an programming book to an invidiual compiler (note that it's also contains of the most complete posix-SQL references in the OSS world). Manuals, yes, documentation, not necessarily. Documentation is often *built* from the source code, or it's source is included with the package source code and docs are generated at compile-time. And as the Django and Python philosophy says, No special case is special enough. Hence, USE=doc gives documentation. Whether generated from source, generated with it, or downloaded and installed. Just stick a USE=doc on -base and be done with it This has an major drawback: requires to do an complete rebuild/reinstall of the whole package if you just need the manual. When setting up an new server, you normally don't need the complete manual installed (assuming you're already confident w/ PQ), but you need it someday later when you have to look up something and other media (web access or printed out) are not convenient/available. Now, there are lots of similar examples where USE flags exist purely to pull in run-time deps that don't require the package to be recompiled for usage, and not being able to specify such deps in an ebuild is a deficiency on the package manager side. The proper solution is to fix the package manager, not to split out such things into separate packages. It generates chaos and inconsistency in the tree, and only delays the fixing of the package manager by giving half-baked solutions. I, personally, don't *need* it at all, but having an separate package makes it more convenient. And I don't see any reasons against that split as long as people are willing to maintain it. One reason I can think of is that people expect USE=doc to give them documentation. They expect that a doc USE flag on a package will give them the documentation. That's how Gentoo works, and so that's how people *expect* it to work. Having a special case for a package just to save a little build time is (imho) not worth the inconsistency. -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: PostgreSQL Status
On Mittwoch, 16. April 2008, Tiziano Müller wrote: 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 [... Of course. I didn't question the dump and reload cycle. Just saying you have to use the dump utility of the old version is not correct and goes against the recommendations of the PostgreSQL developers. Also the annoying pkg_setup() error die stuff in the existing ebuilds has always been superfluous. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What are blocks used for?
* Donnie Berkholz [EMAIL PROTECTED] schrieb:
A slight tweak that you may have already considered: a single package is
split into multiple packages with a metabuild (named the same as the
original single package) in a newer version -- for example, modularized
X.
hmm, let's just thing through this:
foo-1.0 (monolithic) is installed.
foo-2.0 (spliited) should come in by update, depends on fooA and fooB.
Obviously fooA and fooB will conflict with foo-1.0.
How does portage actually behave on merge -u foo ?
IMHO, it would block on foo(A|B) vs. installed foo-1.0, since it handles
each package separately.
To solve this cleanly (and automatically), we'll end up in an transactional
requirement: the whole emerge tree (or at least critical parts of it) run
in their own dedicated environment (sysroot) and are committed in an atomic
step - merging to the running system happens *only* if everything worked
fine (maybe optionally including etc-update ?) and so never leaves the
system in inconsistent state if someting goes wrong in the middle of
this process.
But, ugh, that's perhaps far too much for the current portage approach ;-o
(I'm actually doing so with my own Briegel build system, which is designed
for embedded and crititcal targets)
I strongly suspect that in many (but not all) cases the package manager
could be making users' lives a lot easier than it currently is...
Sounds like a great idea.
ACK. At least there should be some mechanism to tell the user why
exactly this block happened and suggestions how to solve this
(of course, manually written by the ebuild authors). Simply adding
some file per conflict to be printed out should be enough, IMHO.
Maybe this filename could be added in {} directly behind each
invididual dep.
For the example above it could look like this:
fooA-2.0.ebuild:
...
DEPENDS=!foo2.0{$FILESDIR}/upgrade-from-1.0.inf
...
files/upgrade-from-1.0.inf:
TYPE: pkg-split, src=foo
SPLIT-SRC: foo=2.0
SPLIT-PARTS: fooA, fooB
INFO: By version 2.0, foo has been split into the packages fooA and fooB.
INFO: The build process can't run directly, since the new sub packages
INFO: conflict with the already installed monolithic version within the
INFO: build process.
INFO: Removing foo and installing it afresh will solve this conflict.
As you see, the INFO: -Lines are what's printed out to the user,
while the other lines could help portage to solve it automatically
(if it has an special logic for this)
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
-
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Early stabilisation
On Thu, Apr 17, 2008 at 2:33 PM, Samuli Suominen [EMAIL PROTECTED] wrote: Thu, 17 Apr 2008 09:43:59 +0200 Vlastimil Babka [EMAIL PROTECTED] kirjoitti: Okay. So we can just agree it's better if the maintainer tells his reasons when opening the bug, to spare the later clarifications? It works. Do it. While I agree with you, and I think we are free to request stabilization before the 30 days window, I also love when people give details about the stabilization and not just a do it. Emacs team's test plans [1] are the better example. Thanks to them I'm able to save a _lot_ of time figuring out how a package works and which features should test. Some details about changes since last stable are usually useful too. In latest wgetpaste stabilization [2] we are told that this is a trivial bugfix release fixing osl support, so we can just test osl support and skip most of other tests. Also, when a program needs a sample file with some obscure format, I really appreciate when maintainers give a URL to a sample file so I don't need to search for suitable files and can strictly focus on testing. Of course, everyone could continue with the do it style, but keep in mind that adding info like I described above can save a lot of AT work and, as a result, make stabilization process faster. [1] http://overlays.gentoo.org/proj/emacs/wiki/test%20plans [2] http://bugs.gentoo.org/show_bug.cgi?id=211894 Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: PostgreSQL Status
Nirbheek Chauhan wrote: I personally have no opinion about the -base and -server split, since I do not know enough about it. But I am firmly against the -docs split since the doc USE flag is for this use-case, and I see no reason why not to use it. Just stick a USE=doc on -base and be done with it Well, this I can answer: The documentation installed by postgresql-docs consists of both server and base documentation. There's also a 'doc' USE-flag for postgresql-base which pulls in the docs. Besides this, the use case I wrote in one of my last messages for postgresql-base/-server also applies to postgresql-base/-docs or postgresql-server/-docs. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
* Nirbheek Chauhan [EMAIL PROTECTED] schrieb: Manuals, yes, documentation, not necessarily. Documentation is often *built* from the source code, or it's source is included with the package source code and docs are generated at compile-time. ACK. But we first should define what's just documentation (things like readme's, changelogs, etc) and what's and separate manual (book). There's often no general answer for that. Individual package maintainers have to decide this. This has an major drawback: requires to do an complete rebuild/reinstall of the whole package if you just need the manual. When setting up an new server, you normally don't need the complete manual installed (assuming you're already confident w/ PQ), but you need it someday later when you have to look up something and other media (web access or printed out) are not convenient/available. Now, there are lots of similar examples where USE flags exist purely to pull in run-time deps that don't require the package to be recompiled for usage, and not being able to specify such deps in an ebuild is a deficiency on the package manager side. The proper solution is to fix the package manager, not to split out such things into separate packages. It generates chaos and inconsistency in the tree, and only delays the fixing of the package manager by giving half-baked solutions. We have virtuals. Properly used they can be a great mechanism for solving this. One example, where it (IMHO) isn't done properly, is the X-server, where adding another driver (which *IS* an separate package, already from upstream) causes the whole server to be rebuild and also produces ugly circular deps (yes, I know of the PDEPEND workaround). x11-base/xorg-server SHOULD be an virtual. (I already sucessfully did this quite some time ago, but meanwhile its outdated) I, personally, don't *need* it at all, but having an separate package makes it more convenient. And I don't see any reasons against that split as long as people are willing to maintain it. One reason I can think of is that people expect USE=doc to give them documentation. They expect that a doc USE flag on a package will give them the documentation. Right, but again we're at the question, what really belongs to the docs. According your argumentation, the GCC programming guide should be also pulled in by the doc usflag. Do you really want this ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
On Fri, Apr 18, 2008 at 1:15 AM, Enrico Weigelt [EMAIL PROTECTED] wrote: * Nirbheek Chauhan [EMAIL PROTECTED] schrieb: Manuals, yes, documentation, not necessarily. Documentation is often *built* from the source code, or it's source is included with the package source code and docs are generated at compile-time. ACK. But we first should define what's just documentation (things like readme's, changelogs, etc) and what's and separate manual (book). There's often no general answer for that. Individual package maintainers have to decide this. I agree with you here, it's the maintainer's call. Now, there are lots of similar examples where USE flags exist purely to pull in run-time deps that don't require the package to be recompiled for usage, and not being able to specify such deps in an ebuild is a deficiency on the package manager side. The proper solution is to fix the package manager, not to split out such things into separate packages. It generates chaos and inconsistency in the tree, and only delays the fixing of the package manager by giving half-baked solutions. We have virtuals. Properly used they can be a great mechanism for solving this. One example, where it (IMHO) isn't done properly, is the X-server, where adding another driver (which *IS* an separate package, already from upstream) causes the whole server to be rebuild and also produces ugly circular deps (yes, I know of the PDEPEND workaround). x11-base/xorg-server SHOULD be an virtual. (I already sucessfully did this quite some time ago, but meanwhile its outdated) This too, just like split ebuilds, is (imo) a hack, and not the solution. A hack that's used in the tree in several places (-meta ebuilds, xorg-server), and seems more Gentoo-ish, but a hack nonetheless, and hence a half-baked solution that delays the package manager's fixing. Maybe I'm just pushing too hard here, but the state of Gentoo's package managers really irks me, and these workarounds just give temporary relief to the problem. One reason I can think of is that people expect USE=doc to give them documentation. They expect that a doc USE flag on a package will give them the documentation. Right, but again we're at the question, what really belongs to the docs. According your argumentation, the GCC programming guide should be also pulled in by the doc usflag. Do you really want this ? Well, I think you answered this in your first paragraph above, that it's entirely upto the maintainer. If it were upto me, I'd go with pulling in the following with the doc USE flag: - Documentation generated from the source code - Documentation generated *with* the source code - Documentation distributed with the source code (inside the tarball) - Documentation distributed/advertised alongside the package/source code (for instance GIMP help files) -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Enrico Weigelt wrote: * Ciaran McCreesh [EMAIL PROTECTED] schrieb: Hi, Hi Enrico, long time no see! b) Marking that two related implementations are mutually incompatible at runtime because they both provide the same binary. Classical example: MTA's: Traditionally they tend to provide an /usr/sbin/sendmail executable. So you can't have multiple MTAs installed. Here the problem isn't that portage can't give more advise, but the system only allows I see you've been missing this list for a long time. Today it's not politically correct to say bluntly portage but package manager (PM)! (the kind reader can then usually substitue implementation name depending on the e-mail sender) For example, for class d) blocks such as the recent coreutils / mktemp mess, Yes, this is *really* a mess, especially because critical packages are involved here. IMHO the problem is clearly made by the two packages themselves. Actually I didn't track yet who was first, but according to the ebuilds, the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp should be preferred and the coreutils's one skipped. Um no, we should not stick with packages forever for historical reasons. the package manager can suggest to the user to install the new package and then uninstall the old package, rather than forcing the user to uninstall the old package by hand (possibly leaving their system without critical utilities) and then install the new package. Yes, but this requires the ebuild author to provide enough information *very carefully*. Yes, ebuild author should be careful, OTOH the end users wouldn't have to be as much careful as they had to be now when dealing with it themselves. In this specific case, portage could automatically decide to replace the separate mktemp package by newer coreutils. But what happens if some package depends on the mktemp package ? Such deps should obviously be transformed to || ( =coreutils-6.10 mktemp) beforehand. Portage has to catch these deps and map them to coreutils if they provide mktemp (and only for those versions which *really do*). No, it should probably just state there's a dep conflict (as it does now if there are several depends asking for different versions inside one slot). This all adds a lot of complexity, and I doubt it's really worth it. Stating dep conflict should be less complexity, and yes it's worth it. Removing mktemp and properly maintaining the standalone package seems much easier and cleaner to me. Sure, legacy and maintainership burden ftw! Including backporting security fixes! I'm tempted to say we are not debian but since I'm not council... :( Caster signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] What are blocks used for?
Enrico Weigelt wrote: * Bernd Steinhauser [EMAIL PROTECTED] schrieb: Hi, e) A package needs a newer version of another package, but doesn't depend on it. This was the case with KDE4. kdelibs-4.0.x block these packages: !kde-base/kdebase-3.5.7-r6 !kde-base/kdebase-startkde-3.5.7-r1 !=kde-base/kdebase-3.5.8 !=kde-base/kdebase-3.5.8-r1 !=kde-base/kdebase-3.5.8-r2 !=kde-base/kdebase-startkde-3.5.8 I don't know very much about KDE stuff, since I got rid of it for a long time, but IMHO it seems there's an principle problem on the install layout - 3.x and 4.x should be completely separate, never conflicting each other. So some package kfoo either depends on kdelibfoo-3.x OR kdelibfoo-4.x. Of course I don't know whether the problems comes from ebuilds or upstream ;-o If you don't know why the blocks nned to be there then why comment on that? -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Early stabilisation
On Thu, Apr 17, 2008 at 09:40:22PM +0200, Santiago M. Mola wrote: On Thu, Apr 17, 2008 at 2:33 PM, Samuli Suominen [EMAIL PROTECTED] wrote: Thu, 17 Apr 2008 09:43:59 +0200 Vlastimil Babka [EMAIL PROTECTED] kirjoitti: Okay. So we can just agree it's better if the maintainer tells his reasons when opening the bug, to spare the later clarifications? It works. Do it. While I agree with you, and I think we are free to request stabilization before the 30 days window, I also love when people give details about the stabilization and not just a do it. Emacs team's test plans [1] are the better example. Thanks to them I'm able to save a _lot_ of time figuring out how a package works and which features should test. Some details about changes since last stable are usually useful too. In latest wgetpaste stabilization [2] we are told that this is a trivial bugfix release fixing osl support, so we can just test osl support and skip most of other tests. ++, this really helps the testing get done quicker. Also, when a program needs a sample file with some obscure format, I really appreciate when maintainers give a URL to a sample file so I don't need to search for suitable files and can strictly focus on testing. Agreed, the fonts team link to a page using the fonts in the package, which makes the package trivial to test. ++ to them. Of course, everyone could continue with the do it style, but keep in mind that adding info like I described above can save a lot of AT work and, as a result, make stabilization process faster. Most of the time I see the doit bugs is when the package has broad uses(i.e. coreutils and most things owned by base-system), and I generally don't have a problem when the package has many various uses that all had changes. [1] http://overlays.gentoo.org/proj/emacs/wiki/test%20plans [2] http://bugs.gentoo.org/show_bug.cgi?id=211894 Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list pgpTCFPZza2v9.pgp Description: PGP signature
[gentoo-dev] Re: escaping variables in sed expressions
Rémi Cardona [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 17 Apr 2008 07:49:23 +0200: 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. Thanks, someone, for mailing me offlist about this. I'm incredibly sorry it was apparently taken negatively, as I had an entirely different meaning in mind, but it obviously didn't come thru as I intended. I'm not sure I can explain without inserting my foot even further into my mouth, but I'll try. I was intending to acknowledge the potential wound but communicate my respect for the person and the technical expertise and appreciation for fineness of detail I've repeatedly seen him demonstrate. Unfortunately, it seems I screwed up big time and that's not the way it came out; rather than respect, it seemed like dissing. So I unconditionally apologize for screwing up. Again, thanks for rightfully pointing that out, and thanks as well to the person that notified me and tried to help. -- 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: escaping variables in sed expressions
Santiago M. Mola [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 17 Apr 2008 11:51:32 +0200: If that's possible, we shouldn't support it anyway. If someone wants to use /var/tmp/port\/age we'll just stab him, if someone releases a tarball with such filenames we'll stab him, too. Agreed. It's not a question of Gentoo support I'm worried about, but of the absolute statement and someone coming across it and relying on it in a (possibly unrelated) context in which it perhaps isn't possible to rely on, to unknown negative consequences possibly including security issues. Also, as it's in the upthread, just in case someone doesn't get the apology I just sent, let me again unconditionally apologize for the very big screwup I made of things above. It didn't come out the way I intended at all, and I thank someone for rightfully pointing that out, and also the person who brought it to my attention offlist and allowing me to try to correct the problem -- tho I realize it's not something that really /can/ be entirely corrected. -- 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?
Enrico Weigelt [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 17 Apr 2008 21:51:45 +0200: I don't know very much about KDE stuff, since I got rid of it for a long time, but IMHO it seems there's an principle problem on the install layout - 3.x and 4.x should be completely separate, never conflicting each other. So some package kfoo either depends on kdelibfoo-3.x OR kdelibfoo-4.x. Of course I don't know whether the problems comes from ebuilds or upstream ;-o The problem is simply older versions of kde-3 ebuilds. Newer versions have the plumbing necessary to keep v3 and v4 separate, but older versions didn't. So those blocks are on the older versions that didn't. By the time kde4 stabilizes (quite some time as a qualified upstream version isn't released yet, current kde4 will never stabilize), the newer kde3 ebuilds should have been stable for some time, so the blocks are there just in case someone has a real outdated kde3 system and tries to install kde4 as well. If they are going to keep their kde3, they'll need to update it first, to the ebuilds that handle things correctly. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
