Entries Tagged 'smart' ↓

Some users noticed that Smart didn’t have support for URPMI’s newly (?) feature ‘reconfig.urpmi’. After some reading and testing, I managed to make it work, and the last patch proposed on issue248 has been applied into SVN r836.

After my recent call for translators, Pascal Bleser sent us a 100% French translated ‘po’ file for Smart. Very good!

Today we finally managed to reach 100% translation for pt_BR on Smart.

We still need some help. For those reading this blog, that aren’t on our mailing list yet, please join and help us translating to your native language.

de = 692 translated messages, 17 fuzzy translations, 15 untranslated messages.
es_ES = 690 translated messages, 9 fuzzy translations, 25 untranslated messages.
fr = 652 translated messages, 43 fuzzy translations, 29 untranslated messages.
it = 227 translated messages, 15 fuzzy translations, 482 untranslated messages.
pt_BR = 724 translated messages.
zh_CN = (formatting errors, needs further checking)

Following the Smart i18n changes I started yesterday, today we decided to remove the .mo files from the SVN and make them build during install process.

Here’s the changelog for r814:

* setup.py
- extend class InstallData to add _compile_po_files (generates .mo files while installing)
* locale/zh_CN/LC_MESSAGES/smart.po
- add ‘\n’ to line 2662 to make po compile
* locale/*/LC_MESSAGES/smart.mo
- remove .mo files from svn since they are generated during ‘make install’

It’s always nice to have a productive sunday.

I’ve made some modifications to Smart on SVN r813 that I think some people might be interested.

Added the file ‘contrib/smart-completion.sh’. It’s a bit ugly and slower than I wanted to, but it works very nice since it completes options, action commands and even options from the action commands. It was fun to write it.

I’ve added ‘check-po’ into Makefile so it would give statistics about missing translations on the ‘po’ files. If someone wants to use it to update the ‘po’ files, you’re welcome to contribute.

And last, but not the least, thanks to Raúl Moratalla we now have es_ES translations!

Changelog:

* locale/es_ES/LC_MESSAGES/smart.po
- added es_ES translation (thanks Raúl Moratalla )

* contrib/smart-completion.sh
- added bash command completion script

* Makefile
- more verbose output of ‘update-po’
- added ‘check-po’ macro (stats about missing translations)

Gustavo Niemeyer gustavo at niemeyer.net
Mon Nov 6 15:44:46 PST 2006 [link to original text]

Yes, that's right.  0.50rc1 is available, and brings a number of
cool things you definitely should check out, experiment, break,
and report problems about.  

This is the most exciting Smart release in quite some time.
Besides a load of bugfixes, we've got several small improvements,
and one huge feature that was being planned for a long time.

Thanks to Eran Tromer, Smart 0.50rc1 integrates changes in the
transaction algorithm which makes it able to survive massive
whole-distribution upgrades with good results, and in acceptable
timings!

No, just *that* wouldn't make Eran happy enough.. he's also changed
the way that priorities are considered by the transaction mechanism,
so that tracking individual packages from arbitrary repositories is
actually much more predictable and manageable.

In the field of not-so-huge-but-still-cute features, Mauricio Teixeira
has implemented ETA reporting during downloads for graphic and textual
interfaces.

What?  You're still reading!?  Go get it right now!

http://labix.org/download/smart/smart-0.50rc1.tar.bz2
MD5SUM: bd387fd07549751acda1c98745cce6bb

Special thanks to Eran and Mauricio for the great work done.

(hopefully this mail won't get into your spam traps  

--
Gustavo Niemeyer
http://niemeyer.net

(Warning: long post ahead!)

I was reading Mark Shuttleworth’s comment about Consistent Packaging, and although I’ve not yet read all the comments on his post, I have my own concerns that I wish to express here (so I won’t pollute his mailbox with redundant comments, if that’s the case).

As being one big Smart Package Manager contributor, I think I’m eligible to an opinion. We’ve already faced many situations where users suggested to use Smart as the main package manager on their distributions, and we have seen many kinds of reactions to those requests. Many of them generate discussions that tend to fall on the packaging standardization matter, so I think I can say something about Mark’s post.

Before proceeding, remember it’s just my humble opinion. It’s no way related to Smart, it’s development or it’s acceptance. Please, I’m trying to be neutral here.

So the problems I see here are:

1 - Ego

Once I saw a presentation from my friend Osvaldo Santana about how to manage a FOSS project where he said something that would sound similar to this: FOSS developers have a huge ego (…) if you put two of them on a big stadium to defend their ideas, their ego would inflate so much it won’t have enough space for the audience. (Ok, not a direct quote, just what I felt he wishes to say)

And what that means? The battle between RPM and DEB is a long running war, which may still exist for centuries to come. Yes, I know Mark didn’t mention “lets use this” or “let’s use that”, but you know someway, somehow, someone would fall in this topic. And see that I’m not even including tarballs, portage, klik or any other exotic packaging system on this matter!

Even if there’s a magic proposal for an hybrid or a completely new format, people with strong preferences would still battle for including the features they think are better on their preferred format than the other.

Do I have a solution? Obviously not! I’m completely out of this discussion, and I intend to stay like this (at least for now). My feeling is that the people from LSB have what it needs to find a nice solution, even if this solution won’t get widely adopted, which brings us to the next problem.

2 - NDH (not developed here)

I’ve heard that so many times I simply stop counting. And I’m not talking specifically about Smart. This argument is used with many other things, specially system tools, file location standards (let’s not forget FHS either), service handling, system initialization methods/scripts, etc (ok, let’s not divert from the topic).

What I mean is that, along with the previously mentioned ego, the fact that something is not internally developed is enough motivation to simply drop some nice ideas. I’m not saying that all distros act like that, or that the distro developers are self-centric bastards, but you’ve got to admit that if NDH didn’t exist, we wouldn’t have so many Linux distros around. Agreed?

3 - Unleveled development

The NDH issue creates the problem of the unleveled development. Considering each distro team wants/needs/decides to develop a new/modified method to achieve their users/clients/partners goals, every and each single distro is self-centered on a personalized development cycle, with their own goals, needs and methods.

If we completely ignore the previously mentioned problems we could simply expect that all the distros work in sync like on the automobile industry. Even with different products, market shares and niches, most of them work with a nice seasonality: they tend to release the new models almost on the same period of the year, very close to each other.

That, IMHO, would be another great problem to be solved before having a consistent packaging system. The distros would need to work in sync so they always have the same package capabilities, store the files on the same places, have a consistent pre/post scripting system and, who knows, even the same package manager features.

4 - Conclusion

So, my point is: I agree with Mark, to a certain point. We sure should have a very consistent packaging system, along with a strong LSB and FHS and anything needed to make these things work together. We’ve already seen many proposals on that, like United Linux, LCC and even DCC (supported by Mark, I guess).

Despite of all best efforts given on those projects, we’re still here to see any consistent solution that would come from any of them. They all failed most because of the problems I mentioned since I started writing this post.

Hey! Let’s not forget the fact that if we really manage to solve all these problems, the distro maintainers would have enough time to focus on what really matters: innovation, stability, security, and the best user experience.

Bottom lime, let’s drop the cheap talk, put our egos aside and start work on something that would bring true benefits to the Linux world.

I’ve been in the need for this for a long time, now I finally managed to implement. Smart now shows the download ETA (remaining time) for a file (not for the whole transaction [yet]). It’s not a so great feature added, but at least you can have an idea of how long will it take.

Fetching packages...
-> http://software.opensuse.org/download/home:/.../dia-0.95.1-4.1.i586.rpm
dia-0.95.1-4.1.i586.rpm         ####                 (58.0kB/s - 24% - ETA 55s)

Reference: http://tracker.labix.org/issue31

The new release of Smart Package Manager is out on the wild! And now my YaST2 channel implementation is officially supported (so I’m an official co-maintainer, I guess).

From the release notification e-mail:

Gustavo Niemeyer gustavo at niemeyer.net
Sun Jun 25 19:36:57 PDT 2006

Smart 0.42 is out!

I'd like to send special thanks to Michael Vogt and Mauricio Teixeira for the efforts put into this release.

Download information is available at http://smartpm.org

MD5SUM: e60b411ad41dbe2e6fc57a04d82f91cb (check it!)

Changes in this version:

- Support for YaST2 channels (thanks to Mauricio Teixeira).
- New plugin that optionally keeps the channels in sync with
/etc/apt/sources.list{.d}, for APT-based distros (thanks to Michael Vogt)
- New man page (thanks to Christoph Thiel).
- GTK interface now uses GtkFileChooser if available, and uses
buttons order according to the gnome HIG (by Michael Vogt)
- New zh_CN translations (thanks to Funda Wang).
- New rpm-log-file option, passed to the RPM API.
- New option deb-purge, allows passing --purge to dpkg instead of --remove.
- Many bug fixes.

Have fun!

--
Gustavo Niemeyer
http://niemeyer.net

Sorry, but I don’t know nothing about Ubuntu, but this press release caught my attention:

[...] “Edgy Eft is scheduled for release around October 2006 and may include features such as the Smart Package Manager, which claims to make it easier to install and upgrade software, and support for XGL graphics software. [...] support for true mixed 32-bit and 64-bit computing on AMD64, the interesting possibilities of the SMART package manager [...]“

Yes. Looks like Ubuntu is the distro that prove the world that Smart is a viable solution.