package manager

English Programming/Scripting
#1

I want to do a package manager where it handles a variety of package types, deb, rpm, source, bin. Secondly, it should ask on packages like Firefox for example, where to install it. Perhaps in the users home directory, perhaps in /usr/… maybe some place else that the user wants. It should also ask if the user wants the application or service to run in a chroot environment. Ofcourse there should be a setting/option to go with defaults.

The package manager should be able to read the spec file of the deb or rpm and satisfy the requirements. It should not cause conflicts due to deb or rpm packages.

I’d like to do this in python.

Comments, tips, suggestions?

#2

In which programming language do you plan to create this package manager?

#3

As I said in my original post

I’d like to do this in python.

#4

Sorry I am so tired. It will be better to write it in C++. It is the programming language who I know and teach. Try to use Qt-creator or maybe suse studio is useful for you.

#5

You might have a good reason to want to program such a thing. But since you’re asking for suggestions, I would say: Don’t do it! If you create packages for openSUSE, you would use rpms. If you install Debian or Ubuntu packages, either they are so simple that you could just alien them or that are unlikely to work. Btw I wouldn’t be surprised if such meta package managers already exist - and are not used because they are simply not needed.

#6

I don’t know C++ or QT. I’d have to learn it. At least I have some understanding of python.
SUSE studio would not work for this at all. That’s for building an openSUSE distro.

#7

Because it is a Rpm, it will be better to download the rpm builder. software.opensuse.org: Search Results

I can help you if this package manager based on C++ or Qt.

#8

I do have reasons for it. One just to test a theory of mine. I also hope it would lead to a unified package manager and a unified package type, but thats a ways off. I am aware of alien, but I want to do this with out alien. By reading the spec files, scanning the files on the local machine and resolving deps that way.

#9

I have rpmbuilder, but thats for building rpm packages, not package managers.

Check out smart package manager. It was/is written in python. No I am not trying to duplicate that effort. Smart Package Manager - Labix

#10

It is good. I want to ask you which programming language do you know??

#11

Python.

Now I was thinking that when the package manager deals with a package, whether rpm, source, or deb, it could extract it to /var/lib/cache and put the files there, then build the necissary package (rpm or deb depending on the system), that way the package fits the system.

#12

Look it will be better if you want to start something check something same with it. In my opinion you must see the coding of package manager, you must see How this package manager is built.

#13

Umm, ok. See I was with smart package manager for a long time. I wrote one of the plugins for it.
YUM package manager, synaptic is also in python as is portage. Zypper is in C++.

I know quite a bit about package managers, just not a lot about programming.

#14

Because package manager has a way to build. It is not a program but it is a repository(a couple of programs), it is not the same with a normal program. So we need something extra for it.

#15

@Jonathan: the idea comes and goes through time. Over the last ten years there have been loads of articles on this, a unified package manager. It’s also been mentioned as one of the main issues in linux land, the lack of something like this. I don’t have the technical knowledge, never programmed in python, but I support the idea. The only thing I could do is pop a couple of questions now and then, to help you testing it, and propose a name for it: JUPS (Jonathan’s Unified Package System :slight_smile: )

  • What if a package is there in rpm, deps can be met though available as deb?
  • How to handle such a case in one unified database?
#16

Yes, that’s the idea. If there is an rpm deps should be met through any available package whether deb, rpm or source
I might have the database use the systems existing database to read from (but not write to) ur something like (s)locate database, unless someone else has a better idea.

I kinda like JUPS. It’s funny.

#17

We need first the server to run it and through that to become available to all users. It is not something which becomes with DevC/C++ or with Qt or C++. It is something which needs the combination of all. It is a repository.

#18

No, not a repository. A repository is a collection of software either locally or remotely that a package manager connects to. A package manager can be coded in any language I suppose. Mandrivia’s urpmi is in perl. zypper is in C++. Gentoo’s portage is in python as are yum and synaptic. All of these package managers connects to repositories both locally and remotely.

#19

I have in my mind Packman repository. Zypper is in C++ abd yum is in python(optical).

#20

Jonathan R wrote:
> I want to do a package manager where it handles a variety of package
> types, deb, rpm, source, bin. Secondly, it should ask on packages like
> Firefox for example, where to install it. Perhaps in the users home
> directory, perhaps in /usr/… maybe some place else that the user
> wants. It should also ask if the user wants the application or service
> to run in a chroot environment. Ofcourse there should be a
> setting/option to go with defaults.
>
> The package manager should be able to read the spec file of the deb or
> rpm and satisfy the requirements. It should not cause conflicts due to
> deb or rpm packages.
>
> I’d like to do this in python.
>
> Comments, tips, suggestions?

(1) Read all the articles you can find about similar projects, as has
been suggested.

(2) Read the code of the existing package managers, especially those
written in python. Get to understand what they do, and how they do it.
Also, you’ll get an idea of what they can’t do.

(3) Write a list of features that you want your package manager to have
and prioritise them (to get an implementation order)

(4) Starting with one of the existing package managers that you feel is
closest to what you want and/or best written and easiest to understand,
try to add the next feature on your list, preferably by borrowing and
adapting code from the other programs. Repeat a couple of times to get a
feel for the process.

(5) Pick the feature you think will be most difficult and work out what
you will have to do to implement it. This may cause you to rework
existing code.

(6) Repeat 4 & 5 until you feel you understand the whole problem. That
includes any major features that you want to implement later.

(7) Sit down and think about what your final program will look like.
Face up to all major issues. Be prepared to throw away all the code you
have written up to now and start again (it probably won’t be that bad,
but you must keep the option).

(8) Now you can draw up a plan. Especially work out how you can test
your program. Write your definitive list of features and descriptions of
how it will work.

(9) Make all the test data and any test programs that you will need.

(10) Now implement your package manager properly. Test it as you go, and
add more test data as you realize what you forgot before.

Cheers, Dave