Package Manager Repos

Would you want one just for the Pandora?

  • Yes, PORTAGE!

    Votes: 0 0.0%
  • Yes, APT!

    Votes: 0 0.0%
  • Yes, YUM!

    Votes: 0 0.0%
  • As long as it has a GUI I'm fine.

    Votes: 0 0.0%
  • Why not just use SD cards?

    Votes: 0 0.0%
  • All of this is just a bad idea. (Explained below)

    Votes: 0 0.0%

  • Total voters
    0

Laurent said:
This was only an example I know it works fine :)
But what about kernel threading? If CONFIG_HAS_TLS_REG is changed in the kernel config, I guess some applications will fail (e.g. those compiled with CSL gcc).
I know the current kernel config has this flag set, so it should be no problem. But what if in the future a new kernel config option appears that impacts user land apps?
Then we'll slap the people responsible ;)

But seriously, do you think we need to stay cutting edge with the Linux kernel? I'm thinking of the GP2X kernel, and how many times people have complained about kernel version shipped with it that has never changed, and how long its going to take for a version of the kernel to change in such a way that it breaks compat with binaries. 3 years and the Pandora will be pretty much obsolete anyway.

Also, I could understand it more if the entire application was statically linked and having problems with the C library and the kernel, but we are talking about things such as the standard C library, SDL, etc (common libraries that will be shipped with the OS) being dynamically linked, and only statically linking libraries which are not provided by default to save having to put copies of (possibly various versions of) them on sd cards.
 
Last edited by a moderator:
Squidge said:
Laurent said:
This was only an example I know it works fine :)
But what about kernel threading? If CONFIG_HAS_TLS_REG is changed in the kernel config, I guess some applications will fail (e.g. those compiled with CSL gcc).
I know the current kernel config has this flag set, so it should be no problem. But what if in the future a new kernel config option appears that impacts user land apps?
Then we'll slap the people responsible ;)

But seriously, do you think we need to stay cutting edge with the Linux kernel? I'm thinking of the GP2X kernel, and how many times people have complained about kernel version shipped with it that has never changed, and how long its going to take for a version of the kernel to change in such a way that it breaks compat with binaries. 3 years and the Pandora will be pretty much obsolete anyway.

Also, I could understand it more if the entire application was statically linked and having problems with the C library and the kernel, but we are talking about things such as the standard C library, SDL, etc (common libraries that will be shipped with the OS) being dynamically linked, and only statically linking libraries which are not provided by default to save having to put copies of (possibly various versions of) them on sd cards.


But since Pandora is so much more than the GP2X won't the software advanced make more difference? just a thought, Pandora isn't just a handheld game console, it's a Computer with game controls really? the more advanced the more sensitive is usally the way it goes?
 
Last edited by a moderator:
Squidge said:
But seriously, do you think we need to stay cutting edge with the Linux kernel? I'm thinking of the GP2X kernel, and how many times people have complained about kernel version shipped with it that has never changed, and how long its going to take for a version of the kernel to change in such a way that it breaks compat with binaries. 3 years and the Pandora will be pretty much obsolete anyway.

I agree. But I remember why I did not play long with my gp2x: I found it extremely frustrating not to be able to have EABI while still being able to use already compiled applications; yes I know I can be extreme :)

QUOTE
Also, I could understand it more if the entire application was statically linked and having problems with the C library and the kernel, but we are talking about things such as the standard C library, SDL, etc (common libraries that will be shipped with the OS) being dynamically linked, and only statically linking libraries which are not provided by default to save having to put copies of (possibly various versions of) them on sd cards.

gcc startup code is impacted by NPTL.
But in general you are, as often, right :p
 
Last edited by a moderator:
Squidge said:
But seriously, do you think we need to stay cutting edge with the Linux kernel? I'm thinking of the GP2X kernel, and how many times people have complained about kernel version shipped with it that has never changed, and how long its going to take for a version of the kernel to change in such a way that it breaks compat with binaries. 3 years and the Pandora will be pretty much obsolete anyway.
I think that kind of demand will be there, more than you anticipate, but not necessarily as much as the demands behind a modern desktop distro. I believe so mainly because this Handheld has a USB host port, is internet connected, and -is capable- of replacing a desktop / laptop if you're willing to put up with some things.

A periodic update would be nice, and it would be much harder to port lets say, Kernel 2.8 than to simply keep reasonably updated until we hit version 2.8. Not that we are getting close to a major kernel release or anything ;)
 
Last edited by a moderator:
atomicthumbs said:
MechsWillOneDayStepOnYou said:
atomicthumbs said:
synaptic is a no-go
Why?


1. It won't work well on the Pandora's screen

2. I hate Synaptic


Synaptic could easily fit on the Pandora's screen and be used with the touch-screen.

Whats to hate? apt-get install is quicker but I've never had any reason to complain about synaptic
 
Last edited by a moderator:
May not be well known, but pacman is a great package manager. It is simple, fast, and extremely powerful. It is the base for a wonderful distro called Arch Linux, which might also be a good distro to model the Pandora distro off of. While Arch is not meant for embedded systems, it is KISS and extremely flexible. The whole Pacman/ABS/PkgBuild system is well built.
 
dajoe said:
APT FTW! Portage makes no sense on a pandora monoculture where everybody uses exactly the same hardware...
Maybe not in the way you think it would, again using portage tree and some paludis base tools for cross compilation is not that bad idea, on host. And no, i don't want portage tree, nor /var/db/pkg on my device... that would not be sane IMO. :) As such, I am almost certain that i will have busy summer holidays, when device will be made avail for users :D

I will be also interested in _stealing_ some work from maemo.org folks, and putting it in my tree. Later delivering it in deb or whatever form we will decide for publics shouldn't be big deal... (I hope so atleast, never tried it too). So be it rpm, tbz2, deb. I did something similar for bit bigger systems (HPC stuff), but there was no cross compilation.
 
Last edited by a moderator:
Squidge said:
Like stated in another thread, to make things simple and easy for people (and to allow people to easily copy files to and from sd cards), the package manager will not worry about libraries. There will be 'default' libraries which ship with the OS, but any other libraries are expected to be statically linked to the applications that require them.

This way, people can upgrade applications by using drag and drop, and by extracting an archive directly to an SD card on there PC, should they want to install multiple applications and not waste battery life on the console.
I think I'm gonna be sick.
 
Last edited by a moderator:
Blah said:
Squidge said:
Like stated in another thread, to make things simple and easy for people (and to allow people to easily copy files to and from sd cards), the package manager will not worry about libraries. There will be 'default' libraries which ship with the OS, but any other libraries are expected to be statically linked to the applications that require them.

This way, people can upgrade applications by using drag and drop, and by extracting an archive directly to an SD card on there PC, should they want to install multiple applications and not waste battery life on the console.
I think I'm gonna be sick.


Heh, you and everyone else with half a brain.
Static linking of all but base libraries just doesn't make sense, since the base platform becomes bloated. Let them be dynamic and just use a decent package management system. You can always make a GUI for any package management system, but that is not a good enough reason to employ such a huge limitation.
 
Last edited by a moderator:
Megamixman said:
Heh, you and everyone else with half a brain.
Static linking of all but base libraries just doesn't make sense, since the base platform becomes bloated. Let them be dynamic and just use a decent package management system. You can always make a GUI for any package management system, but that is not a good enough reason to employ such a huge limitation.
I kept saying that, but no one seems to listen. Not to mention upgdates are a chore without package management.
 
Last edited by a moderator:
I'm not extremely knowledgeable on the topic of libraries. However, it seems like software developers like using nifty new features of recently released libraries, and library programmers like fixing bugs. Having the libraries dynamic and managed by a package manager would make this easier... Right?

As an aside, I'm pretty pleased with the simplicity of the iPhone Installer app (as a method of browsing installable apps, not getting into the technical merits of how it handles meeting installation requirements and such).

For all other package installs, I just use command line. :)
 
Megamixman said:
Heh, you and everyone else with half a brain.
Static linking of all but base libraries just doesn't make sense, since the base platform becomes bloated. Let them be dynamic and just use a decent package management system. You can always make a GUI for any package management system, but that is not a good enough reason to employ such a huge limitation.
That isn't what he said. What I believe has been decided is that the system will include lots of libraries; all that most people will need. Only unusual libraries will need to be statically linked (this saves faffing around with dependency tracking and means people don't need to install extra libraries into the root filesystem). Of course, if a developer wishes to dynamically link a non-standard library they could of course include it in the package and have a launch script that sets up the appropriate environment variables to tell the linker where to find it.
 
Last edited by a moderator:
Orkie said:
That isn't what he said. What I believe has been decided is that the system will include lots of libraries; all that most people will need. Only unusual libraries will need to be statically linked (this saves faffing around with dependency tracking and means people don't need to install extra libraries into the root filesystem). Of course, if a developer wishes to dynamically link a non-standard library they could of course include it in the package and have a launch script that sets up the appropriate environment variables to tell the linker where to find it.
Yey, a person with a full brain that interpreted what was said correctly, instead of someone with half a brain interpreting it completely wrong ;)
 
Last edited by a moderator:
Squidge said:
Yey, a person with a full brain that interpreted what was said correctly, instead of someone with half a brain interpreting it completely wrong ;)
I'm proud of having half a brain. Which proves that I do.
 
Last edited by a moderator:
Orkie said:
Megamixman said:
Heh, you and everyone else with half a brain.
Static linking of all but base libraries just doesn't make sense, since the base platform becomes bloated. Let them be dynamic and just use a decent package management system. You can always make a GUI for any package management system, but that is not a good enough reason to employ such a huge limitation.
That isn't what he said. What I believe has been decided is that the system will include lots of libraries; all that most people will need. Only unusual libraries will need to be statically linked (this saves faffing around with dependency tracking and means people don't need to install extra libraries into the root filesystem). Of course, if a developer wishes to dynamically link a non-standard library they could of course include it in the package and have a launch script that sets up the appropriate environment variables to tell the linker where to find it.



The only reason a non-standard library should be statically linked is if that library was developed solely for that application. Otherwise, it is highly likely that something else uses it, and is better off dynamically linked.

The issue over dependencies is a non-issue. Linux package management has gotten to the point where it more then capable of handling dependencies without problems.

Finally, a base system with all the 'necessary' libraries so to speak is not a good idea. People have different apps they want, and the definition of 'necessary' is going to differ from person to person. Again by keeping the bloat minimal, and letting a good package management system take care of things, people will get the libraries they need for the programs they have not a million others.
 
Last edited by a moderator:
Megamixman said:
The only reason a non-standard library should be statically linked is if that library was developed solely for that application. Otherwise, it is highly likely that something else uses it, and is better off dynamically linked.
Yes, I agree, on a desktop system.

However, on a handheld, not so good. For example, someone removes one of the applications that uses the library, deletes the library assuming it's no longer needed, and finds some other programs no longer work. Or they copy an application from someone elses SD card (or downloads an app from the web using there PC as they don't have Wifi), forgets to download the library, and gets frustrated when they find out it doesn't work. All these equate to bad user experience.

Like has been said before, we are trying to keep this as simple as possible - Download app, throw it onto an SD card (or copy from another), done. No dependencies = no hassle.
 
Last edited by a moderator:
Squidge said:
Like has been said before, we are trying to keep this as simple as possible - Download app, throw it onto an SD card (or copy from another), done. No dependencies = no hassle.
That's where I see the problem. That means a nightmare updating the app. Users could be educated to get stuff from the repository and there's always the option of apt-file.
 
Last edited by a moderator:
sindbad said:
That's where I see the problem. That means a nightmare updating the app.
Not really, rarely will apps need to recompiled due to library changes, and if it becomes a problem or you don't like to statically link, you can always bundle the library with the app. This means the app still works regardless of how its installed.
 
Last edited by a moderator:
Back
Top