Entries Tagged 'smart' ↓

Considering the recent announcements on OpenSUSE-factory mailing list regarding future dropping of YaST2/YOU repos for SUSE in favor of RPMMD/ZenWorks, and considering I am the one who is in charge of developing the YaST2 support, there’s something I need to say.

Our plans of adding YOU repos to Smart has been delayed. We’ll be waiting for the final release of SUSE 10.1 to make a final decision about it. Meanwhile, anyone who is using YaST2 repositories should add the old APT ones for “update” and “security” (which are officialy implemented in YOU).

The YaST2 support on Smart remains maintained, and is planned to be merged on the main code by the next official release.

Thank you.

Productive days, indeed.

• Add YaST2 channel support (recommended update)
• Show from which channel a package is selected (solution suggestion only)
• A package name only change list (solution suggestion only)

Yesterday I released the first public patch to add YaST2 support into Smart.

- Mailing list announcement
- Additional note
- Tracker entry

I’m expecting to hear from the brave people that are willing to test it.

Smart 0.41 has been released yesterday. Among many modifications, I would like to call your attention to a better support for RPM Metadata (rpm-md), that now uses cElementTree as a parser, speeding up cache loading. It also implements the first ‘test’ framework (more on that later). And last, but not the least, four new features coded by me, and one bug fix (SUSE freezing) that I helped.

Ok, this is my blog, isn’t it? This is the first Smart release that comes with some code as an official contributor, so I’m pretty happy with that. I hope to contribute more in the future.

By the way, read the release mesage. Once again, thanks Pascal Blesser for being the first packager among all (Guru’s RPM for SUSE).

There’s been some interesting discussions about users asking for Smart being oficially supported on Fedora Core. Some obviously won’t agree, while others don’t bother and are just working to add the package to contrib (extras) repositories.

- FedoraForum.org
- RedHat Bugzilla
- fedora-devel-list (thread “What about smartpm?”)

Yesterday I received the green light from Gustavo Niemeyer to start coding YaST2 repository support into Smart. It will take some weeks (probably months) to get it working stable, but I’ll have Pascal Bleser and Christoph Thiel working along, helping me understand and testing it. We hope we can get it working with as much capabilities as possible.

Great news! Smart freezing on SuSE has been fixed. As I’ve said before, it was needed to code a workaround on Smart so it bypasses some erroneous behavior on SuSE’s RPM.

Official notice and rationale can be found on Smart’s mailing list archive.

Pascal Blesser, from Guru’s RPM Site, already packaged a patched version of Smart, and it will be available soon on mirrors.

Again, just to be sure, this was not Smart’s fault, but an unpatched error on SuSE’s RPM.

There are many reports around about Smart freezing on SUSE. Niemeyer (Smart’s main coder) and I are working to solve this and here’s what we’ve found out so far.

SUSE runs a non-pached RPM 4.1.1 (old) with a known bug that makes child threads to not return SIGCHLD in very specific cases (some strange specific %post scripts), which makes it very difficult to track from Smart. This is a known issue, and has been corrected on many other distros when they were using this same version, although most are now using newer releases, which don’t have the bug. We think it’s not easy to solve that way, since we couldn’t find strong arguments to justfy the upgrade of RPM on SUSE.

There are a few workarounds for that, and the easiest one is using Smart into stepped mode (option “–stepped” on the command line). This can be explained because the more packages you enqueue on the same transaction, the more you raise the probability of a missing thread somewhere. So breaking each transaction into smaller sub-transactions would slow down thread creation and possibly avoid freezing. There are other tricks that can be done on the code level, but we prefer not to suggest them since we’re not sure about long term results using it.

The fact is that YaST and YOU won’t have the same problem since they work on a higher level from RPM. Smart threats packages on a more refined way, and deals directly with the rpm libraries, while YaST works almost like a wrapper, so it doesn’t see the same level of details as Smart does. Maybe that’s why SUSE never bothered upgrading RPM.

So, we’re absolutely sure that it’s NOT an Smart issue (no way). It’s really a problem on how RPM works with many concurrent threads on the same transacion, and this bug only exist on RPM 4.1 and older, but SUSE didn’t bother upgrading yet, and we haven’t asked it since we want to avoid biger problems that could possibly be caused by such upgrade on a stable release.

Bottom line, it’s just a matter of time for us to come up with a solution. Meanwhile, patience is a virtue.

–en
Easy Urpmi is a very famous site among Mandriva users because it provides an easy way to locate on-line media mirrors, and a cut’n'paste interface to Urpmi commands. Now, with a handful patch from me, it also works with SMART!

–pt_BR
Easy Urpmi é um site muito famoso entre os usuários de Mandriva porque provê uma maneira fácil de localizar mirrors de mídias on-line, e uma interface copiar&colar para comandos Urpmi. Agora, com uma modificaçãozinha feita por mim, ele também funciona com SMART!

This message was on the cooker mailing list, and I thought it was interesting to cite here, since it gives another idea of what’s coming with the Smart Package Manager. The discussion started about how urpmi handles the RPM Requires(post).

On Fri, Aug 19, 2005 at 03:11:00PM +0300, Andreas Hasenack wrote:

This is a real bug in rpm, and a bad one. Ordering packages for installation is
very important.

I have a similar behaviour with the kolab packages. There are these
three:
- kolab (requires the two below)
- kolab-webadmin (Requires(pre): kolab)
- kolab-resource-handlers (Requires(pre): kolab)

Below I have 3 cases: rpm, smart and urpmi. All installing these 3 rpms.

Due to these requirements, correct ordering dictates that kolab be
installed first. It’s what happens when I use smart to install these
rpms, for example, but rpm itself isn’t doing it. Look at the order
(and the error I get due to this incorrect ordering):

# rpm -Uvh kolab-resource-handlers/RPMS/noarch/kolab-resource-handlers-0.4.1-0.20050811.1mdk.noarch.rpm kolab/RPMS/i586/kolab-1.9.5-0.20050801.1mdk.i586.rpm kolab-webadmin/RPMS/noarch/kolab-webadmin-0.4.9-0.20050812.1mdk.noarch.rpm
Preparing… ########################################### [100%]
1:kolab-resource-handlerswarning: user kolab does not exist - using root1%)
warning: group kolab does not exist - using root
warning: user kolab does not exist - using root
warning: group kolab does not exist - using root
########################################### [ 33%]
Adding user apache to group kolab
Adding user cyrus to group kolab
Adding user postfix to group kolab
Adding user ldap to group kolab
2:kolab ########################################### [ 67%]
3:kolab-webadmin

See who got installed first? kolab-resource-handlers, that is, the
“Requires(pre): kolab” it has wasn’t obeyed.

smart installs them in the correct order:

# smart install kolab-resource-handlers/RPMS/noarch/kolab-resource-handlers-0.4.1-0.20050811.1mdk.noarch.rpm kolab/RPMS/i586/kolab-1.9.5-0.20050801.1mdk.i586.rpm kolab-webadmin/RPMS/noarch/kolab-webadmin-0.4.9-0.20050812.1mdk.noarch.rpm
(…)
Preparing… ##################################################################################### [ 0%]
Output from kolab-1.9.5-0.20050801.1mdk@i586:
Adding user apache to group kolab
Adding user cyrus to group kolab
Adding user postfix to group kolab
Adding user ldap to group kolab
1:Installing kolab ##################################################################################### [ 33%]
2:Installing kolab-resource-handlers ##################################################################################### [ 66%]
3:Installing kolab-webadmin ##################################################################################### [100%]

urpmi happens to work, but it doesn’t obey the kolab-webadmin Requires(pre): kolab
restriction:

# urpmi kolab-resource-handlers/RPMS/noarch/kolab-resource-handlers-0.4.1-0.20050811.1mdk.noarch.rpm kolab/RPMS/i586/kolab-1.9.5-0.20050801.1mdk.i586.rpm kolab-webadmin/RPMS/noarch/kolab-webadmin-0.4.9-0.20050812.1mdk.noarch.rpm

installing kolab-webadmin/RPMS/noarch/kolab-webadmin-0.4.9-0.20050812.1mdk.noarch.rpm kolab/RPMS/i586/kolab-1.9.5-0.20050801.1mdk.i586.rpm kolab-resource-handlers/RPMS/noarch/kolab-resource-handlers-0.4.1-0.20050811.1mdk.noarch.rpm
Preparing… #############################################
1/3: kolab-webadmin #############################################
Adding user apache to group kolab
Adding user cyrus to group kolab
Adding user postfix to group kolab
Adding user ldap to group kolab
2/3: kolab #############################################
3/3: kolab-resource-handlers#############################################

After that, there is another observation:

On Fri, Aug 19, 2005 at 03:19:00PM +0300, Andreas Hasenack wrote:

Actually, it was pure luck. urpmi also doesn’t do proper ordering. All I
had to do was change the order in the command line:

# urpmi kolab/RPMS/i586/kolab-1.9.5-0.20050801.1mdk.i586.rpm kolab-webadmin/RPMS/noarch/kolab-webadmin-0.4.9-0.20050812.1mdk.noarch.rpm kolab-resource-handlers/RPMS/noarch/kolab-resource-handlers-0.4.1-0.20050811.1mdk.noarch.rpm

installing kolab-resource-handlers/RPMS/noarch/kolab-resource-handlers-0.4.1-0.20050811.1mdk.noarch.rpm kolab-webadmin/RPMS/noarch/kolab-webadmin-0.4.9-0.20050812.1mdk.noarch.rpm kolab/RPMS/i586/kolab-1.9.5-0.20050801.1mdk.i586.rpm
Preparing… #############################################
1/3: kolab-resource-handlers##############warning: user kolab does not exist - using root
warning: group kolab does not exist - using root
warning: user kolab does not exist - using root
warning: group kolab does not exist - using root
###############################
Adding user apache to group kolab
Adding user cyrus to group kolab
Adding user postfix to group kolab
Adding user ldap to group kolab
2/3: kolab #############################################
3/3: kolab-webadmin #############################################

bang!
(smart doesn’t fall for this trick, btw)

You can view the complete thread on the archives with title URPMI and Requires(post).