Package management

English Open Chat
1

etc.

Ok, my problem with Opensuse package management is essentially that it’s divided in ways too many different repositories. When I want to install an application, I launch Yast, type the application name, search and it’s not there. I have to search the Build service or Google to get it - and sometimes it’s simply not available. Maybe I have too specific needs, but just after installation I have 20 (!) different repositories. I understand oldcpu’s claim that he’s a strong supporter of ONLY OSS, Non-OSS, Update and Packman, but there’s so little software that it’s useless for me.

I (everybody) install many packages and on a fresh install and I wasn’t able to find these in Yast:
wicd
geany
scipy
matplotlib
amarok 2.2
playonlinux
qalculate
virtualbox
smplayer
crystal decoration for kwin
thunderbird 2
stellarium
VLC

I was able to find some of them on the Build service, but not all of them. And some of them failed to install.

Let’s start with wicd. I don’t know who decided that there will be network-manager by default, but it’s a really bad choice, at least on my laptop (it’s not only opensuse problem, kubuntu does it too). It just doesn’t work - and it never did, on any distribution, whether is it opensuse, debian, ubuntu or gentoo. AFAIK it’s not even finished, it should be ready by the time KDE 4.4 is out. Anyway, I want to use wicd as it works flawlessly for me. Besides the fact that I need to take a wire and connect manually with ifconfig, there’s no wicd available in Yast. I have to add the Enlightement repository. WTF? Wicd is commonly used on both KDE and Gnome, not to mention various WM’s like Fluxbox or Icewm.

Ok, let’s add Geany, Numpy, Scipy and Matplotlib. I use these almost daily. Geany is in some new repostory, the same for matplotlib. Numpy is already installed, but scipy isn’t. Interesting, these packages are usually complementary. Nevermind, let’s search for scipy. It’s available in the build service, but the installation fails.

Next comes Amarok 2.2 (it’s ways better than 2.1). It installs fine from the build service, but it again adds a new repo and brings some conflicts between versions (easy to sort out, though).

Qalculate, Smplayer, Thunderbird, VLC are the same - search the build service and add a new repo.

Virtualbox works fine for the time being, but I always use my own kernels, so I’ll have to recompile vboxdrv as soon as I get to compiling my new kernel. Maybe there is some modules manager and their (re)compilation front-end, but I haven’t found any yet. I’d like something like opensuse alternative to Debian’s module-assistant.

Next I need to install Wine, because I need to open .doc files that OOo doesn’t handle. Wine is available, that’s fine, although it’s not the newest version. I like to use some frontend (a habit from CrossOver), so let’s install Playonlinux. Not there, nor on the build service. Google didn’t help me either.

Stellarium is also not available, nor is crystal style for kwin.

Proprietary codecs install fine, except k3b-codecs, but I suppose it will catch up soon with newer k3b.
Just out of curiosity, there’s no mp3 playback in the official distribution because it’s not free. Okay, I undertand that. But is flash player more free than mp3?

So now, right after installation, there are 20 repositories enabled (and no, I don’t want to disable them. I want my packages to be updated):

garion@linux-apn7:~> zypper lr
#  | Alias                                                    | Name                                                     | Enabled | Refresh
---+----------------------------------------------------------+----------------------------------------------------------+---------+--------
1  | Education                                                | Education                                                | Yes     | Yes
2  | KDE:Backports                                            | KDE:Backports                                            | Yes     | Yes
3  | KDE:KDE4:Community                                       | KDE:KDE4:Community                                       | Yes     | Yes
4  | Libdvdcss repository                                     | Libdvdcss repository                                     | Yes     | Yes
5  | Packman Repository                                       | Packman Repository                                       | Yes     | Yes
6  | devel:languages:perl                                     | devel:languages:perl                                     | Yes     | Yes
7  | devel:languages:python                                   | devel:languages:python                                   | Yes     | Yes
8  | home:TI_Eugene:QtDesktop                                 | home:TI_Eugene:QtDesktop                                 | Yes     | Yes
9  | home:dmitry_serpokryl:Enlightenment-cvs-core-metapackage | home:dmitry_serpokryl:Enlightenment-cvs-core-metapackage | Yes     | Yes
10 | libdvdcss                                                | libdvdcss                                                | Yes     | No
11 | mozilla                                                  | mozilla                                                  | Yes     | Yes
12 | mozilla:legacy                                           | mozilla:legacy                                           | Yes     | Yes
13 | openSUSE:11.2:NonFree                                    | openSUSE:11.2:NonFree                                    | Yes     | Yes
14 | openSUSE:Factory:Contrib                                 | openSUSE:Factory:Contrib                                 | Yes     | Yes
15 | packman                                                  | packman                                                  | Yes     | No
16 | repo-debug                                               | openSUSE-11.2-Debug                                      | No      | Yes
17 | repo-non-oss                                             | openSUSE-11.2-Non-Oss                                    | Yes     | Yes
18 | repo-oss                                                 | openSUSE-11.2-Oss                                        | Yes     | Yes
19 | repo-source                                              | openSUSE-11.2-Source                                     | No      | Yes
20 | repo-update                                              | openSUSE-11.2-Update                                     | Yes     | Yes

Starting Yast’s package installation module takes several minutes as all the repositories refresh - pretty inconvenient when I want to install a package quickly to test it. Why can’t I decide when will I refresh the repositories (just like when I can decide when to run aptitude update)?

Moreover, when I want to check some new applications somebody tell me about, I read about (e. g. here)or whatever, it’s usually not available and one has to search the net - and it’s sometimes not available at all.

Okay, let’s return to the beginning, where some people claim that Opensuse package management is superior to Debian’s. In Debian, I can install every single package of those I mentioned just with the default repositories, just one fast command (aptitude install <package>) and I’m done. I can also be fairly sure that when I want to test some new programs, it will be there. And there is the super-convenient module-assistant

P. S. please don’t take me wrong. This is no rant against opensuse. I love the distribution and I always recommend it to newbies - and I was happily using it for quite long. This is merely a reaction on oldcpu’s claim quoted above.

2

In general I agree as coming from Mandriva, where the 3 common repositories (main, contrib, and plf) contain just about all the software you could need, I found this splitting things into tons of Buildservice repos quite off-putting. I’m going to give Opensuse 11.2 a try and see how it goes, and go back to Mandriva if it doesn’t go well.

However virtualbox, thunderbird and smplayer are already available in the default repository set. playonlinux is in packman but hasn’t been updated for 11.2 yet, since it’s not out. PackMan :: Informationen zum Paket PlayOnLinux

3

I have to agree that (what I call) repository proliferation is a growing problem with openSUSE.

At the same time, I think it is also a symptom of an exciting future for openSUSE, where every user can create their own repository (for sharing of rpms).

There are problems here, that openSUSE needs to address. I’m not 100% convinced other distributions have solved this problem, because I’m not convinced 100% other distributions have encountered this problem to the extent openSUSE has encountered it. I am NOT convinced other distributions have (encountered and solved) this problem because I do not think it is really as easy on other distributions, as it is easy on openSUSE, for every user on other distributions to create their own repository. On openSUSE it is relatively easy.

Part of the difficulties we have, is users, who create their own repos, do not always use a consistent baseline in creating their packages. In truth, in some cases it is not practical for them to do so. In order for their packages to build they need to use a different baseline. They may need updates created by other users on different (but specialized) repositories. So they may then put dependencies in their packages (on their repos) that have to be met, but that means if one does not know of the other (specialized) repository, then the application will fail to install (or possibly fail to run).

Another problem is some users, to “scratch an itch” will create a repository with a number of useful applications. They will tell people of this repository to briefly help with a problem, but then a short time later, they will remove their repository, just when people begin to rely on the repository. Now the users who 1st created a home respository are under NO OBLIGATION to continue with their repository, but defacto by creating it, they have intentionally or not, created expectations which can lead to disappointment. Other users, who had the same “itch”, but not the knowledge to create rpms/custom compile, are suddenly faced with a solution disappearing when the repository disappears.

This is a problem - where I do not see a solution. But despite it being a problem, its not a BAD problem, … ie other distributions simply make it harder for their users to create repositories, which to me is NO solution. I prefer making it easier to create repositories.

Hence in despite this openSUSE repository problem, I still think openSUSE is better for repositories. But what I believe we may need is a way of categorizing repositories, which is more formal than we have now. That view of mine is controversal, and many people do not subscribe to that idea.

There are also many repositories in the build service, with many applications, that are constantly kept there by the users who package them, but most people are not aware of, nor are they picked up by webpin. Should they be?

Also, there are many repositories with “names” to them, but no list as to who the maintainers are, nor a consolidated list as to who the contributors/packagers are, nor a list/description explaining what the purpose/intent of a custom repository is … and frankly, to have to download every rpm just to figure out what the purpose of the respository might be, and just who the packagers are, seems to me to be something we can improve on. Possibly some sort of auto generated list is needed.

So I confess I completely agree that repository proliferation is a problem with openSUSE, but I also believe despite this, the benefits openSUSE has obtained from repository proliferation completely outweigh the criticisms.

BUT we do need to find a way to warn new users to be careful, and I’ve tried to do that by lecturing, harping, pontificating, shouting, repeating, … anything I can do, to tell users to stick with OSS, Non-OSS, Update and Packman, and ONLY add others once they understand the implications, risks and know how to solve resulting problems.

… for users who find this “free wheeling” repository proliferation on openSUSE is determental to the distribution, and feel this justifies their moving to a different Linux distribution, … to me that is a good justification. It is not a justification that I agree being something that would sway me to change (as I believe this respository proliferation can lead to openSUSE being a much better distribution), but I totally understand where the frustrations could come from and why some users do not want to be here during the teething problems.

This (repository proliferation) is an area of tremendous potential for openSUSE, but its also an area where there will be some serious teething pains.

All IMHO, of course! :slight_smile:

4

Some good points there oldcpu. However I don’t think it’s so clear cut that consolidating repositories would make it harder for users to setup their own.

For example Mandriva has their contrib repository which are RPMs contributed by users and mandriva developers which aren’t officially supported by Mandriva. This repo still has security/bugfix updates but I think it’s less on-time than the supported repo (equivalent of opensuse’s OSS).

I think it would be good to extend the existing contrib repo for Opensuse into something like this by feeding in well-used (and tested) packages from the various Buildservice repos. That way anyone’s still free to chuck their latest and greatest creation into the Buildservice but a more stable subset gets copied into the contrib repo from where it’s easily added to YAST to expand on the relatively low numbers of packages available in opensuse’s repos.

5

That is a lot of text to read :stuck_out_tongue:

However it’s not really true that opensuse is alone with easy user repositories, i would rather say all the *buntu’s have it easier with launchpad. So in this case you get a huge software library from start with *buntu/debian and then you can add new repositories easy which gives updates for the software or new software. For example you can install kubuntu and then add the kubuntu-backports ppa which gives updated KDE and updated KDE software such as amarok etc…

6

I think that (having one repos where such packages can be fed) is a good approach for part of the solution. But I do not believe it to be sufficient, as I think it can be restrictive. In fact two users can package the same application, of the same version, but because of build options the applications will have different capabilities. How is that handled?

Also, users can put a package in that common repos, and then its support disappears when they disappear, and then breakage can happen (and possibly dependency problems, possibly not) when other packages are updated that depend on an update of the no longer supported package.

Also, some packages by some users may be built to a low quality, … and those built by others to a higher quality. Such a repos would then be branded with the quality label of the poorest quality package. As it is now, I know of some private repos where those users who put packages there, build them to a high quality. Hence I will frequent those, but will not frequent others, strictly based on my quality assessment from my experience.

How do we sort that ?

The issue is big. The issue is exciting. And I think it gives openSUSE a potential edge. I know other distributions have encountered this on a smaller scale, and I think their solutions were less than adequate, as their solutions (IMHO) of one contribution repos stifled contributions. …

It will be very interesting and neat to see this subject debated, and hopefully a positive and interesting way forward.

In the mean time, I think we are very fortunate at the solid baseline that the Packman repos brings, such that users can stick with OSS, Non-OSS, Update and Packman, while the other issues are sorted (adding other repos temporary on an adhoc addition/removal basis for individual apps only when required).

From my, indubitably biased view, this is a fun and an excellent time, to be part of the openSUSE community.

7

Hi
That’s what the contrib repositories are for already on OBS, from there
AFAIK they can get added to the standard install.
http://en.opensuse.org/Contrib

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.37-0.1-default
up 13:45, 2 users, load average: 0.13, 0.10, 0.09
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.18

8

I’m afraid that this concept of “every company has it’s own repository” is a dangerous thing.

It has some very good points as oldcpu pointed out, but I see some drawbacks.
Above all, it discourages authors from opening their sources - they can ship the final product very easily without sharing the code. In my opinion it’s better if an author just puts his sources somewhere on the net (sourceforge or something) and if it’s good, developers and maintainers of various distribution will package it.
This concept obviously works well - Debian has over 25 000 packages in it’s repositories, more than any other distribution.
It requires more work from the maintainers - but it ensures that only programs that are worth get to the repository and it also ensures consistency, because there must be certain conventions on the package name, versioning and content layout (this is exactly the reason Gentoo users and devs laugh at Debian that Debian maintainers patch everything all the way to hell and back). And the user benefits, because it very efficiently prevents the repository proliferation.

I definitely think that all open source programs (GPL and more free licenses) should be in one central repository, there is no reason for them not to be. If anybody want to build his own repository, why bother when he/she could put it straightly to the main repository? Of course, there’s a danger that low-quality programs will get there, but it’s easy to sort out. People gain access to the repo only after they prove trustworthy, and if a newcomer wants to put his program in the repo, he can ask the current maintainers to put it there.

Other drawback is the repository proliferation, IMO it’s horrible to have 20 repositories after the installation - and it’s not finished yet.
And with repository proliferation come dependency problems, there are duplicate versions available and which one should the dependency handler choose? Besides when creating a repo, I can rely on some dependencies to be in some other popular repo, but some people might not have it, or have a different version etc. I’m afraid it will be a great mess - it’s already starting to be.

When it comes to proprietary software, the maintainers of course cannot adjust it to the standards of the main repo, so there must be new repositories. That’s what e.g. Opera does.

EDIT: I see a lot of new text appeared here before I’ve written this :slight_smile: . This is a reaction on oldcpu’s first post here only :slight_smile: .

9

Let’s review the development and packaging process. An author (individual, company, whatever) writes a program and shares it on the web (it’s usuall called “upstream”). Then a distribution maintainer takes it, adjusts it to his repo’s conventions and puts it in the repo. Every repo has a list of packages it contains and every package has a maintainer assigned. So there is no danger of two people packaging the same program.

When I cannot continue maintaining a package, upgrading it, solving bugs etc., I tell that to the community and if the program is worth it, somebody else takes it. Of course it can take some time and some breakages can occur, but from experience they usually don’t and if they do, their only impact is that an upstream version is skipped. Generally this is a broader problem of the whole community and distribution structure to ensure that important packages will always have a good maintainer.

In the end, having one single repository itself sorts some of the possible problems you have mentioned. There won’t be multiple users packaging the same program, because each package has it’s own maintainer. And if some programs don’t meet the quality standards, the maintainer can be changed by the community. Of course, if it’s low quality comes from upstream, there’s not much the distribution can do about it anyway (we all remember KDE 4.0 :slight_smile: ).

10

While I agree with some of your post, I think some of your specifics are possibly unique to yourself?

I can’t speak for gnome, but for KDE4, wicd is not the DEFAULT wireless management package “of choice” for all of openSUSE.

Now having typed that, you have a point in that the Network Manager on KDE4 does not yet work well. Users need to do extra work here to configure that they should not have to do. For many users wicd DOES work. I had it on my laptop, and it worked well for a while. My wife, a winXP user, LOVED it and actually preferred it over what MS-WinXP had to offer (go figure). BUT, then wicd stopped working after I kernel update (which makes NO sense to me) and so I removed it. My wife is no longer happy. But this problem is not unique to openSUSE.

I have encountered this in YES, YES in debian based distribution.

I still use Amarok-1.4 (I think). It just works. Do I really want some feature in 2.2 ? Not really. When its ready I’ll go for it, but it is not something that is going to stir up my emotions for a distribution. Is 1.4 ready now for openSUSE? Yes. Does 1.4 work well NOW on openSUSE? Yes.

These ALL work well for me. I use vlc and smplayer from Packman repositories. Wonderful.

I keep my thunderbird up to date from the mozilla repos. It also works wonderful.

I can’t undertand where the problem is there that you encounter.

I have the same. But as you know, Virtual Box tells me the EXACT command to send each time. So in truth, it is not difficult. I honestly can not see this as a problem wanting me to give it a seconds thought wrt being unhappy with a distribution.

wine, I keep updated from the wine repository. The version on the education repository is identical to the wine repository. I add the repos, update wine, and remove the repos as required.

But I do NOT simply willy nilly update wine. Thats a sure way to do an update that breaks an app. Its far better IMHO to update only when needed.

I have no problems with k3b-codecs. Possibly because I still use the KDE3 version of k3b. But even if I did not install k3b-codecs, I don’t use them. There are other apps that I signficantly prefer to use, when it comes to what one might use k3b-codecs for.

IMHO flash is living on “borrowed time”. I do not believe it will last long.

Oh boy. You know my view on this. OSS, Non-OSS, Update, and Packman. No others. None. Not one. Add others only on an adhoc basis for individual apps, and remove immediately after. ONLY keep them if you know enough how to solve the dependency and other breakages problems that one can encounter.

I must have posted that over 100 times, … and users still ignore me because “they know better” and when they have problems they storm off because of the nightmare of dependencies, when if they had listened to some common sense, things would have worked.

Does openSUSE need improvement here? I would say yes. Is it a nightmare? I would say not if one listens to my advice. Is it a nightmare when one ignores my advice? I would say its possible. One has reap what they sow.

You want your packages updated? Not that way will you achieve. You are digging yourself a hole, and ignoring advice given on a forum, and then blaiming the distribution is IMHO not a problem with the distribution. The problem lies elsewhere somewhere after the keyboard … my apologies if that reads like a criticism, but in truth, when I am given good advice from a Debian user, and I ignore it and I have problems as a result, I don’t blaime the Debian distribution, rather I look in the mirror and see the fault.

I do not use these applications. They could be night mares to install. But I do use dozens and dozens of other 3rd party apps that work well.

Let me ask this. Have you tried to contact any of the packman packagers to see if any might help in packaging some of those? If so, what did they say?

Last time I ran synaptic on a debian distribution, it was worse. I also find zypper faster than apt-get.

Actually, I tried some of those on a Debian distrubion and almost 1/2 did not install with the default. Now I am confident I could have joined the appropriate forum, and got an answer how to install most, but thats not my point. My point is they do NOT all install by default. So I am rather suspicious of your facts.

Anyway, don’t get ME wrong. I concede openSUSE package management is not perfect. OpenSUSE has some big challenges ahead because of the repository proliferation.

But at least 1/2 of the cases you cite are not problems. And in at least 1/2 of the apps you cite, I had problems with debian.

So where does that leave us? Your experience/feelings on openSUSE were worse than mine on Debian? hmmmm…

Frankly, I don’t want to go down the “my feeling is better” road. I would rather try to improve things that need work, BUT FIRST ensure the criticism is accurate. I do think there is more to amaork, k3b-codecs, vlc, smplayer, thunderbird, etc … that are simply your experience that is either not openSUSE specific, or it is something that you did wrong, possibly because of the excessive repos you setup. I dont’ know. I do know they work well on 7 of the openSUSE PCs I maintain.

11

I completely disagree.

When compiling a package there are often MANY options one can specifiy. Dependant on the option that is specified, that can COMPLETELY change the behaviour of aspects of the package that are VERY VALUABLE to some of us.

I do not think it does.

Only if you refuse to let someone else build the package.

Lets say you build package-a but do not use option-a, option-b, nor option-c in compiling, either because its too difficult, or because you can not get it to compile, or because you simply think its not needed and you do not care.

On the other hand, lets say I can build the package with all 3 options workikng perfectly. BUT YOU are the “authorized” packager. To boot, you and I have had disputes, and you refuse to have anything to do with me, and we say you refuse to accept my advice on how to build the package so as to pickup those 3 options.

So where are we? We have a distribution with a package built that is crippled.

With more than one repository, there is a way around that.

This is just ONE example of a problem with the one repository approach. Its possible there are others if I take the time to type and explain it.

No, IMHO while repository proliferation IS a problem, it is also exciting in what it offers. It helps to address some of the, shall I say, political aspects that can cripple a distribution, where there is excessive control.

Well, quality is another point. Identifying quality and changing a packager is not easy. Remember, they are volunteers. Not everyone wants to volunteer. I can name cases where a packager decided to quit, and NO ONE, NOT ONE, wanted to step up and package the applications.

Thinking that one can “just replace” a packager without a lot of difficulty, and without possibly years (yes years) of no package being packaged, does not fit in with my experience in opensource Linux.

12

Hi
As a minor packager using OBS, the same issues arise when packaging if
there is a dependency issue when building. OBS will let you link to a
prebuilt package, but which one do you use :wink: I tend to start at
contrib and education as they tend to be on the ball so to speak.

Personally I don’t have the time to look at putting the ones I build
into contrib if there is enough interest in a package I would prefer if
it’s picked up by someone in contrib or packman. If you look at some
recent examples.

  1. Chromium-browser. There was a request to help in getting a spec file
    done to package this up by user BenderBendingRodriguez which I
    helped with. Which in turn was picked up and pursued by dbuck, in a
    very short time it was then added to contrib.

  2. Handbrake. There was a request from someone on usenet to package
    this up which I had been doing from svn on a monthly basis, however
    from memory user TheMask asked on here about it, he took the ‘bull by
    the horns’ and approached packman to build, which they did. Again
    without too much fuss.

I do maintain some specific one for a couple of users, but they
generally advise me if there is an update or need help with the
developers which I’m happy to do.

Bottom line the ‘home’ directories on OBS are just that ‘home’ I move
stuff, change stuff, if you have linked to it then you may/will have
problems :wink: If you do then I would expect an email to me (see the rpm
changelog) asking what the issue is and would more than likely help to
sort it out.

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.37-0.1-default
up 14:18, 2 users, load average: 0.13, 0.04, 0.01
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.18

13

Hi
My claws-mail build is like that, I have an ISP specific patch for the
usenet server, plus numerous configure options disabled as I don’t use
them, as well as my own tray icons :slight_smile: But it is noted in the details.

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.37-0.1-default
up 15:01, 2 users, load average: 0.08, 0.07, 0.01
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.18

14

Well, let’s put aside Network Manager’s and Wicd’s quality. That’s not the point. The point was that I want to use Wicd. I just do. For whatever reasons I ever might decide. And I expect the distribution to allow me to install it easily. Especially when it’s quite a popular program (AFAIK). Adding Enlightement repository to get Wicd is well…unexpected to say it mildly.

Debian based distribution is (by definition) not Debian. Please note that what applies to Ubuntu doesn’t generally apply to Debian.

You’re lucky then. But again, for whatever ever my own reasons, I want Amarok 2.2, and again I expect the distribution to allow me to install it (easily if possible). It’s the current stable version of Amarok after all.

Yes, the work well for me too. But I had to search them on the internet, because I didn’t find them in software installation module of yast.

Thunderbird from mozilla repos is a beta version. I want the stable - again for whatever ever my own reasons (in fact because one extension I want doesn’t work with it whereas it does work with Thunderbird 2). And again, I expect the stable release of a distribution to allow me to easily install stable Thunderbird. Now I have to search it on the net.

Ok, I apparently didn’t do my homework thoroughly enough. But I’ve spend several hours searching and in the end I’ve found installing it from Sun’s website as the easiest way. Note that I talk about installing virtualbox on my own (not the distribution) kernel, so the problem is with compiling vboxdrv.

Yes, add new repos. I’ve managed this too :slight_smile: . But I’d prefer not adding more and more and more repos.

Ok, that’s your opinion.

Ok, use whatever you want, but the default in 11.2 is KDE4 k3b, so one would expect appropriate k3b-codecs available.

You mean enable a repository, install a package and than disable it? Well, again I’ve maybe didn’t do my homework thoroughly enough, but it seems like a very silly idea to me. This way you deliberately get rid of security updates and bugfixes. That’s definitely not the way to go, at least for me. Besides you bring dependency problems. When a package from this disabled repo depends on a certain library from some enabled repo and it changes, it can easily break the package. And even if with library update comes the package update to keep working together, I’d not get the package upgrade and be left with broken package.

So tell me a better way to keep all my installed packages updated. Disabling their repos is the opposite, I only achieve that they won’t be update.

Good for you. But I do use them.

Synaptic is a ****. Anyway, what do you mean by “debian distribution”?

What exactly are you talking about?

Of course they are not problems. The problem is that I have to search the web to find them instead of package manager. And enable twenty repos to get them.

Could you be more specific?

Well, all I’m trying to say that I have to search web and enablo a lot of repositories to get the packages I want. That’s not a feeling. I get them OOTB in Debian. That’s also a fact.

15

Let me expound further.

There is ONE repos for 3rd party IMHO. Its packman. But for a NUMBER of reasons, many people want to package applications and share the results of their efforts and they do NOT want to be FORCED to be packman packagers.

OK ?

So lets say we create just one repos anyway. Lets say we FORCE users to put their rpms in that one and only repos.

Lets say you are packager-a (again) and you package that rpm with option-a, option-b, and option-c, but NOT with option-d, because YOUR EXPERIENCE is that option-d will break many other applications. Lets say the majority of your fellow packagers agree with you.

Lets say I can package the application with option-a, option-b, option-c, AND option-d. And I know of say 200 people who can use my packaged rpm, who do not need option-a, b, nor c, but NEED desperately option-d. Now my 200 is a small number compared to the 1000 who download your packaged app. But I am NOT allowed to put my packaged app on the ONE AND ONLY repos, because you and your fellow packagers refuse to, because you are afraid it will break things for the 1000, … and you are right.

So what happens to my 200 ? They are left out to dry, because no one is allowed to package the app for my 200 and put it on the repos.

Now yes, there are ways around this. Ways that require corresponding back and forth, to create different versions, with different names, but in an effort to mitigate the risk to your 1000. but the risk WILL still be there. and it will there after gosh how many emails/posts/irc-chats back adn forth debating the issue.

With the repos proliferation, I just create my package. Its there. No disputes. No emails. No chats. No posts. Its there. and so is the risk still there.

Now that is a problem, and its a blessing. And rather than adopt the NO only one repos approach, I prefer to look for other solutions. I think we should find other solutions, than what I think is a one repos only approach.

Now do not get me wrong. I think the Packman packagers are GREAT. I’ve said a number of times, they are the MAIN REASON I stick with openSUSE. … But I do think the possibility of other repos other than just Packman opens a door for a tremendous opportunity , but one that needs a lot of work to avoid repository proliferation problems.

So, I’ve given you 2 examples. One based on a disagreement between packagers because they don’t like each other, and one because each is trying to address a different need, ALL with the same application.

I suspect there are other examples.

so in the end I do NOT like the one repository approach.

16

Well that sums it up then. And its all your opinion too.

OK, I’m out of here. I won’t try to debate that sort of answer

17

A binary distribution must be compiled with as generic options as possible. If anyone needs something special, it’s very easy to do a backport, especially with OBS. For example I want to use custom kernels, so I simply compile it with my specific options on arbitrarily limited distribution. If you have more packages that need special treatment and parameters, there are wonderful source distributions.

Anyway, if you make a custom package, no one is preventing you to share it, either as a single package or as a repository. But it doesn’t change anything on the fact that one would expect all of the generic applications in one place. I don’t need a specifically tweaked scipy or geany or smplayer or playonlinux. I want the generic ones. And with the current style of managing repositories I have to search the web instead of package manager to get them.

18

Ok, that’s your opinion.[/quote]

What else should have I said? It is your opinion and whether I agree or not doesn’t change anything, given that we don’t discuss application breakages when updating wine.

19

Not true. Say for example you compile some app. For the basic options, you start off with ./configure and thats it. Now that’s a basic set up. However, I know from experience, that quite a few apps not only need configure options set, and make flags set, but alot of packages are patched.

Let me illustrate a set of configure options for a very basic and essential package…rpm. Even rpm configure and compilation varies from distro to distro. So Here is an example for you.

>./configure prefix=/usr --with-popt=/usr/local --with-db=internal --with-db-tools-integrated --with-zlib=external --with-bzip2=external --with-xz=internal --with-file=internal --with-lua=internal --with-sqlite=external --with-syck=internal --with-beecrypt=external --with-openssl=external --with-gcrypt=external --with-neon=external --with-pcre=internal --with-xar=internal --with-popt=external --with-keyutils=external --with-pthreads --with-libelf --with-python --with-perl --with-build-extlibdep --with-build-maxextlibdep --enable-build-pic --enable-build-versionscript --enable-build-warnings --enable-build-debug

Now you see there, that would work on quite a few builds, but I have noticed, that openSUSE puts popt in /usr/lib64 and /lib/ not in /usr/local, so then that set of configure options would not work with openSUSE. On top of all that, I’ve had to set LDFLAGS in the makefile.

Actually, it’s not always easy to backport. It’s more easy to break apps when you backport. I was talking to some devs in #opensuse-kde about the menu launchers that you could do in kde from the pannel. Just right click, add menu. They said they could do a backport for it, but then some up and coming changes would break it. The reverse can also be true. When backporting, it may work with what you wanted, but it may break other apps. So while scipy, geany, and smplayer maybe apps that you want, as most of us want at least one of those apps, then you must realize that apps have to be compiled to openSUSE specs, and often patched. I know for a fact, that the packman team often patches applications. These are custom patches done by packman.

I was writing a book on a particular package manager called smart. In that I cover a lot of usage and explain the history of package management. Perhaps you might want to take a look at it. https://docs.google.com/Doc?docid=0ASHKrxvS2lMlZGN6ZDZtandfNWt0YzhoZmhz&hl=en

Before you start talking about building packages, you should really get an idea of what goes on in a build. What a spec file looks like. What requirements must be met. What obsoletes what and so on. You clearly have no idea of this process.

As I just said, you clearly have no idea of the build process, and you come off as ignorant and arrogant. Trying to convince others to something you have no idea on the subject. Here is a tutorial. SUSE Build Tutorial - openSUSE Please also read this Packaging/SUSE Package Conventions - openSUSE

Now also understand I am not in any way trying to insult you. Just that this is an area that you have not studied on, and it shows.

20

I don’t think anyone’s talking about ‘FORCING’ anyone to do anything. You have one 3rd-party repo, say contrib, which contains packages from the build service which have commonly used ./configure options enabled and which has been tested to some degree (or at least widely used).

You can then still have the proliferation of hundreds of repos in the build service which can seek to provide any and every permutation of version, ./configure options or whatever that anyone needs.

The conflicting ./configure option problem is overstated by some in this thread I think. If the problem was so serious it wouldn’t be possible for the OSS and Packman repos (not to mention all the other distros out there) to provide packages that satisfy the needs of the vast majority of users.