devel

devel@lists.centos.org

2 participants
4653 discussions

Fwd: Using probe dependencies for ordering
by Jeff Johnson 31 Mar '09

31 Mar '09

Niels: I've been assembling the necessary implementations to __REALLY__ solve the useradd ordering issue for the last few years. Thanks for the impetus to finally attempt to deploy a solution. Flaps down, headed on final approach pattern to the release runway ... Gonna take a few months still ... 73 de Jeff Begin forwarded message: > From: Jeff Johnson <n3npq(a)mac.com> > Date: March 30, 2009 12:47:57 PM EDT > To: rpm-devel(a)rpm5.org > Subject: Using probe dependencies for ordering > > This thread (I chimed in late solely because using PreReq: > never solves any problem in reliable packaging imho) > > http://lists.centos.org/pipermail/centos-devel/2009-March/004250.html > > leads me to attempting to ensure that RPM orders packages > so that dynamic events (in this case adding a user) occur > before they are needed. > > There's a whole class of these run-time ordering issues, from > daemon restart to cache rebuilds, that are often not ordered > correctly, leading to endless discussions of the best way > to solve rather mundane issues. > > The problem is intrinsically run-time because an event > (like a cache rebuild or adding a user or ...) needs > to precede the installation/erasure of some other package. > > There's all sorts of solutions that have been proposed, > some solutions work better than others ;-) The typical > approach is to overload dependencies like > Provides: user(foo) > and then attach some semantic to the existence of a > value in rpm dependencies. That approach can take you > only so far because the string represents an > intrinsically run-time condition without actually > testing that the run-time condition is satisfied. > > E.g. adding a user through a %pre script represented by > Provides: user(add) > is only as good (or bad) as the execution of the > script itself. One never knows whether the user > was actually added, only that the user was *supposed* > to have been added, tying the success of an end-luser > upgrade to the quality of the packagers scripting > abilities. > > However, the fundamental problem of representing a dependency > on a dynamic event (think: adding a user) that usually occurs in the > middle of > rather large upgrade transactions using static dependency > assertions is rather confusing. > > I'm gonna call the (solution to the) problem a "Dynamically Ordered > Event" > (or DOE for short) because I gotta call it something. > > There are already several DOE relations that are used for > (partially) ordering packages installs and erases already. > > The most important DOE event (now handled in @rpm5.org code) is > Install before erasing a package on upgrade. > RPM does not compute file dispositions correctly > unless install occurs before erase. The ordering > relation is a DOE because (obviously) the installation > of the new instance before the old instance is removed > is dynamic and solely within the scope of running a transaction. > > Other DOE events (that were added to RPM5 in February) include > ensuring that a package that contains a directory is installed > before any file is installed in that directory. > > Similarly, the end-point of a symlink is used as a DOE relation > when ordering packages to ensure that the end-point of a symlink is > installed before the symlink itself. > > (aside) > There's another _HUGELY_ important DOE condition in RPM that > should be instantly obvious: > Never erase a package instance if the new instance > was not installed successfully. > But that DOE condition is handled through other means (i.e. > doubly linked package upgrade chains) than by permuting the > order of package installation and erasure. > > (another aside) > Whether DOE relations (like parentdir/linkto dependencies) > are _NECESSARY_ or _USEFUL_ for installing *.rpm packages is quite > controversial years after implementation. Adding DOE relations is > demonstrably not _NECESSARY_, RPM has survived (and @rpm.org ;-) > without using that information for more than a decade, there > are other means to constrain ordering with existing dependency > relations. > I do claim that the the added DOE relations are _USEFUL_ because > of the increased determinism in transactions, with less "partial" in > the > package ordering. Additionally, the data in the added DOE > relations is *guaranteed* to be accurate because hierarchical > file paths and symlink end-points always exist, no fuss, no muss, > no packaging policies or reviews are ever needed. > > So I believe its time to start using DOE events (like adding > users, restarting daemons, rebuilding caches, etc) to > package ordering much like parentdir/linkto and install-before-erase > are currently being used. > > The major problem with treating useradd like parentdir dependencies > is how to detect the condition while installing. Unlike parentdir > dependencies, useradd is run by a script that can/will fail. > > Which brings me to run-time probe dependencies. As implemented, > run-time probe dependencies are strings that map to a dynamic run-time > test. E.g. (as implemented @rpm5.org, ymmv) this dependency > Requires: user(foo) > tests that getpwnam("foo") has a return code of 0 rather than whether > some package some where contains a matching string > Provides: user(foo) > (Note: I'm deliberately ignoring details that both the strcmp(3) and > the getpwnam(3) probe will be done if necessary, and also that > probes are not currently > run against added packages but only against the "system" whatever > that means). > > The important point is that (as implemented @rpm5.org) the user(foo) > probe tests the condition that indeed, "foo" can be looked up rather > than that some package happens to contain a matching Provides: of a > string. > > The remaining pieces of the puzzle have to do with establishing > the points in time where DOE relations are evaluated. At the > point where packages are ordered, the script containing the > useradd has not yet been run (and may fail when it actually is > run). So there's a need to attach a post-condition to the > running of %pre (where useradd is typically done) to verify > that indeed a user was added. There's also a need to test > the precondition when installing a package that needs to do > chown(2) on some file path with the uid returned by getpwnam(3) > (i.e. exactly what the Requires: user(foo) dependency tests). > > The above pins down the exact points in time, using pre-/post- > conditions > where the probe is meaningful. > > What remains is to attempt to use the DOE relation while ordering > packages. As currently implemented, that basically means that > %pre scripts need to be parsed to detect that useradd is being > attempted, with whatever user, and a DOE relation needs to be > added before the user is actually added so that the package > that is attempting to add the user is installed before other > packages that need to do getpwnam(3) in order to do chown(2). > > I think I've covered all the necessary details to attempt a > DOE relation for adding users. Adding groups is not significantly > different. > > I also claim that other probes, like /sbin/ldconfig cache rebuilds, > can be mapped into DOE relations. Note that the code base @rpm5.org > already has the run-time probe > Requires: soname(libfoo.so) > and there are further run-time probes that can be evaluated as > pre-/post-conditions during package installation/erasure as well > as being used as DOE relations for ordering. > > Opinions? > > 73 de Jeff > > > >

2 1

s390 tree
by Sascha Thomas Spreitzer 29 Mar '09

29 Mar '09

Hello crowd, I suggest the following: A new mailinglist, probably centos-devel-s390(a)centos.org and a separate IRC channel on freenode probably: #centos-devel-s390 And some wiki Space to appoint ppl and share knowledge. -- Mit freundlichen Grüßen, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/

1 0

RPM of BrOffice.org
by Thiago Avelino 27 Mar '09

27 Mar '09

Morning staff, here in Brazil we can not be using OpenOffice.org because of trademarks and patents, I am sending the mirror of BrOffice.org that in the mirror of the CentOS-BR.org http://mirror.centos-br.org/broffice/stable/3.0.1/RPMS/ It would be very good for the people that download the CentOS here in Brazil the BrOffice.org already came installed. -- att. Thiago Avelino Programador | SysAdmin Linux User: #484673 Asterisk User: #63483 Digium User: D1039273 São Paulo - SP / Brasil www.avelino.us | www.centos-br.org Linkedin | linkedin.com/in/thiagoavelinoster Twitter | twitter.com/thiagoavelinost JustinTV | justin.tv/thiagoavelino

7 18

RPM of BrOffice.org
by Claudio F Filho 26 Mar '09

26 Mar '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi My name is Claudio Filho and i was the L10N lead and yet am the marketing contact and native language to Brazil and pt-BR of OpenOffice.org project. Recently, Thiago told with me about the BrOffice.org(Broo) and i asked why haven't the Broo in CentOS. Today, he sent me informations about this list, i read all the thread, and now i will try to reply all questions about this thread. Just to make some things a little clearer. The name "Open Office" is trademarked in Brazil. The logo, splash and other branding elements are not. The trademark itself is registered in Brazil's Patent and Trademark Office[1] (INPI) and can be checked at their site. Unfortunately there is no direct link... [1]http://www.inpi.gov.br/ Because this problem, the owner of brand/trademark started a juridic campaign to get money of people that are using "OpenOffice*" in Brazil and requesting compensations($$) from developers like the brazilian OOo team and Sun Microsystems. They have *goods* lawyers, and we has luck of to get help with lawyers of Federal Gov for our defense. The result is that all user (win, mac or linux) that use a program 'OpenOffice*' (can be "Open Office", "OpenOffice" or "OpenOffice.org"), by interpretation of INPI, is breaking the copyrights of owner of the brand. So, by determination of Federal Government, is denied the use of "OpenOffice*", and the official option is BrOffice.org. To protect our devels and users, we created a NGO (with the same name) and registered the brand 'BrOffice.org' saving our necks (and of our users) of juridic problems. In 2006, i spoke with Rene Engelhard, lead of OOo team in Debian, about our problem and he created a "semi" meta-package[2] of Broo in him distro. Why "semi" meta-pkg? Because this pkg depends of OOo pkgs and have more the files and changes of name and images (splash, about, etc), with ~3.8Mb. [2]http://packages.debian.org/sid/broffice.org Today, for brazilian users that uses Debian haven't legal problems, and what Thiago (and me) wishes is extend this legal situation to brazilian users of CentOS. Ah! and the more important is that Broo NOT IS a fork of OOo. Broo is the pt-BR OOo! This question was discussed in the OOo Council and approved, and reflected in our page[3] inside of OOo Project. [3]http://br-pt.openoffice.org/ Best regards Claudio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknLbdwACgkQ0U74969cpYkgrQCeORaaTZcwiHbFxlHNmQag/xXt VwAAnREt4+SODl0Uyae+Zlsp3mxkzMq9 =wmS6 -----END PGP SIGNATURE-----

4 4

SPARC Beta el5 SRPMS ?
by d b 25 Mar '09

25 Mar '09

To all... I know the Sparc EL5 port is beta/alpha/gamma... I was able to install base server package using a tftp image. ls -la /tftpboot/tftp64.img -rw-r--r-- 1 root root 9154949 Mar 24 16:39 /tftpboot/tftp64.img I even was able to download the recent curl-7.15.5-2.1.el5.4 update from redhat and rebuild it... (After installing alot of other rpms) . Using "sparc32 rpmbuild -ba specfile" worked like a champ.. Great job. The Sparc EL5 port works in my book. How can I get the SRPMS used to build the sparc el5 port?... It looks like a few have sparc specific changes/additions... For example... silo-1.4.13-8.c5sparc.src.rpm initscripts-8.45.17.EL-1.c5sparc.1.src.rpm There are others but I can only find a couple at http://sparc.centos.org/os/SRPMS/ Some of the rpms were recently rebuilt so someone is using t2000-c5 for fun.... Thank you... David Ultra80 with 4 CPU's uname -a Linux lpaper 2.6.18-53.c5sparc #1 SMP Mon Mar 10 21:50:16 CDT 2008 sparc64 sparc64 sparc64 GNU/Linux grep cpu /proc/cpuinfo cpu : TI UltraSparc II (BlackBird) ncpus probed : 4 ncpus active : 4

1 0

twitter
by Ulrich Leodolter 24 Mar '09

24 Mar '09

> Twitter is a free service that lets you keep in touch with people > through the exchange of quick, frequent answers to one simple > question: What are you doing? Join today to start receiving CentOS's > updates. quick? haha...

1 0

An introduction and a s390 effort
by Sascha Thomas Spreitzer 23 Mar '09

23 Mar '09

Hello contributors and OSS friends, (Who am I?) My name is Sascha Thomas Spreitzer and I live in the eastern outback of Munich in Bavaria Germany. I am 23 years old and started with C and GNU Linux in the early age of 13. (What am I doing?) Most time I spend in the office fixing Unix dependant problems. Since now at Germanys biggest stock broker "Baader Bank". In future (starting first of April) ill design and realize AIX and z/Linux environments for the government insurance sector. If I'm not in the office, I go out with my girlfriend Lisa and we enjoy the little time we have together. I used to do traditional Shotokan Karate in JKA style. But stopped it a year ago, because I had no time left to do it. In holidays I try to gain progress with my software development skills. (Why centos and what I'm up to?) I had a chance to get a look at IBM's z/Series in the past and it arouse my interest. Some years passed and now I have to face z/Linux in my new position. >From the skills I gained in the past and the skills i'll gain in future, I want to contribute back to the community. Since a decade I'm using OSS and I deeply esteem the freedom. It's time for me to contribute. PS.: you can can IM me via IRC or Jabber: irc.freenode.net: sspreitzer Jabber: icefox(a)im.relinked.org -- Mit freundlichen Grüßen, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/

3 6

Forum migration: newbb_to_phpbb
by Alain Reguera Delgado 23 Mar '09

23 Mar '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Guys, During the last few weeks I've been working on a migration script (newbb_to_phpbb) based on a code provided to me by Marcus Moeller to move Xoops+CBB forums, topics and posts into phpBB system. The users are copied from xoops user table onto an LDAP server. More information in the wiki page: http://wiki.centos.org/WebsiteVer2/forums/newbb_to_phpbb It would be nice if you could test this application, and check the overall process so we can get what we need to migrate newbb to phpbb. The application's download link is in the wiki page above. Note that it is in a test mode yet and requesting for comments. Best Regards, - -- Alain Reguera Delgado <al(a)ciget.cienfuegos.cu> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org iD8DBQFJx6kDyXxCQEoXDZARApRNAJ0b3BHLIKJtTCLmHZup2LyDq+FIswCg3GNA AGrAbi69dWEfQmpLesXH5c8= =BWg6 -----END PGP SIGNATURE-----

4 11

CentOS-2 key expired (resend)
by John Newbigin 23 Mar '09

23 Mar '09

I though I was going crazy because rpm would not accept my password to sign some new rpms. The problem is however that the gpg key has expired: pub 1024D/16FF0E46 2004-03-15 CentOS-2 Key <centos-2key(a)caosity.org> sub 2048g/63E158BD 2004-03-15 [expires: 2009-03-14] Who is looking after keys now? Do I need a new one or should I try and extend the old one? The caos key which was used to sign the key has also expired. Advice is most welcome. Thanks John. -- John Newbigin ITS Senior Analyst / Programmer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin

2 1

Missing updates for apache for centos 5.2
by Robert 20 Mar '09

20 Mar '09

Hi, I'm missing security updates for centos 5.2 since a few days. There is at least one security issue for apache, which is fixed in the upstream but not via yum for centos. Did I miss something? Regards Robert

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel