Page 3 of 8 12 3 45 Last »
Reply
Thread Tools
qgil's Avatar
qgil is offline qgil
2009-06-19 , 20:47
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#21
A pragmatic way to approach all this is to apply the peer pressure on any Fremantle app popping up in a private repository, leaving the activity on the 4.1 repos on a lower priority.
 

The Following User Says Thank You to qgil For This Useful Post:
mikkov is offline mikkov
2009-06-19 , 20:51
Posts: 1,208 | Thanked: 1,028 times | Joined on Oct 2007
#22
One way to discourage private repositories is to allow direct install links in maemo.org/downloads only for applications which are in extras repository.
 
Ed_ is offline Ed_
2009-06-19 , 21:00
Posts: 93 | Thanked: 73 times | Joined on Sep 2006
#23
Originally Posted by mikkov View Post
One way to discourage private repositories is to allow direct install links in maemo.org/downloads only for applications which are in extras repository.
Or to not allow to add repositories in application manager
 
qgil's Avatar
qgil is offline qgil
2009-06-19 , 21:02
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#24
What is clear is that maemo.nokia.com will feature only community apps hosted in maemo.org extras.

Also, as a collateral note, now I don't recall whether this has been mentioned anywhere but the Fremantle Application Manager doesn't offer any UI to install deb packages directly. This will be still possible via command line, which is a message probably clear enough for the non-advanced users.
 

The Following User Says Thank You to qgil For This Useful Post:
zerojay's Avatar
zerojay is offline zerojay
2009-06-19 , 21:28
Posts: 2,669 | Thanked: 2,555 times | Joined on Apr 2007 @ Halifax, Nova Scotia, Canada
#25
Originally Posted by Ed_ View Post
And what should user do?
Imagine the situation: User installs all those 60 repositories and uses them. After some(very short) time of installing software from there she faces installation problem caused by conflict between library a from repository A and library b, which is conflicting with library a and required by package, which user tries to install. How user should know what's the problem and how to fix it? By not using repository A or repository B, or what? She even doesn't know from which repository out of those 60 she installs software.

This and many similar situations just can't happen if user would use Extras with minimal QA.
And these situations wouldn't happen if the repo owner would do his own QA as he/she should, which the original poster said was impossible for some reason... and I still haven't heard anyone explain why it's impossible when plenty of other external repositories do exactly that. (The repo owner being lazy isn't a good reason.)

Also, if Extras is so easy to get into, we're going to come to a point where QA won't be so minimal anymore because there will just be a flood of apps coming in. At some point, it'll need to be capped... and when that happens, someone's probably going to start another repo.

As much as I do like having everything in one repo and I like having things organized in one place, going around and asking repo owners to close down is an uncomfortable proposition.

This feels like a microcosm of Linux itself, doesn't it? Why isn't there just one distro of Linux? Why not ask them to shut down their forks? Everyone can get their packages from the same place, QA would all be simpler, user experience would be better, etc, etc... Well, some people just have different ways of doing things... or they just want to operate outside of the norm. Or they need to tweak things so that it runs better on their small embedded machines.
Last edited by zerojay; 2009-06-19 at 21:40.
 

The Following User Says Thank You to zerojay For This Useful Post:
Ed_ is offline Ed_
2009-06-19 , 21:44
Posts: 93 | Thanked: 73 times | Joined on Sep 2006
#26
Originally Posted by zerojay View Post
And these situations wouldn't happen if the repo owner would do his own QA as he/she should, which the original poster said was impossible for some reason... and I still haven't heard anyone explain why it's impossible when plenty of other external repositories do exactly that. (The repo owner being lazy isn't a good reason.)
It's almost impossible for owner to check all possible conflicts with software from other repositories.
It's better to show on the example: Owner of repository A releases new version of library a to his/her own repository. There are 60 other repositories, which potentially have conflicted version of library a. Moreower, new repositories are being created each day and new versions of library a or other libraries/applications potentially conflicting with each other are uploaded to those repositories every day or more often. What kind of proper QA our owner should perform and how often? Should he install all possible combination of applications/libraries before releasing library a? I doubt that anyone can do that. But in one well maintained centralized repository (Extras) it's not a big deal to check.

Also, if Extras is so easy to get into, we're going to come to a point where QA won't be so minimal anymore because there will just be a flood of apps coming in. At some point, it'll need to be capped... and when that happens, someone's probably going to start another repo.
We're far from it. Look at big distros like Debian & Ubuntu. They have a lot more packages in their repository and somehow manage to maintain them and test.
More packages means more users and more testers, not only more maintenance work.

This feels like a microcosm of Linux itself, doesn't it? Why isn't there just one distro of Linux?
No it doesn't. It feels like maintaining package base well-known and proved way. Look around - you'll easily find a lot of examples.
Last edited by Ed_; 2009-06-19 at 21:56.
 

The Following 6 Users Say Thank You to Ed_ For This Useful Post:
zerojay's Avatar
zerojay is offline zerojay
2009-06-19 , 22:11
Posts: 2,669 | Thanked: 2,555 times | Joined on Apr 2007 @ Halifax, Nova Scotia, Canada
#27
I don't remember saying that external repo owners should do QA against every single repo out there. I mean testing against the main repos (including Extras). I do see your point in your example... but that's a pretty extreme case.

Yeah... maybe they should just remove the option for external repos all together. And disallow installing .debs from the command line too.
 
Ed_ is offline Ed_
2009-06-19 , 22:17
Posts: 93 | Thanked: 73 times | Joined on Sep 2006
#28
Originally Posted by zerojay View Post
I don't remember saying that external repo owners should do QA against every single repo out there. I mean testing against the main repos (including Extras). I do see your point in your example... but that's a pretty extreme case.
Even if private repositories will be checked against main repo[s] it doesn't mean that they will not be conflicting between each other. And it's not extreme case at all. It's what we have at the moment. Actually we have even worse situation - repository owners don't check their packages even against Extras and other big repos.

Yeah... maybe they should just remove the option for external repos all together. And disallow installing .debs from the command line too.
Well, commanline is for devs&geeks. They mostly know what they do.
But users would really benefit from disallowing option for external repos. Unfortunately it's too late to do that.
Last edited by Ed_; 2009-06-19 at 22:21.
 

The Following 3 Users Say Thank You to Ed_ For This Useful Post:
attila77 is offline attila77
2009-06-19 , 23:16
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#29
Originally Posted by qgil View Post
Also, as a collateral note, now I don't recall whether this has been mentioned anywhere but the Fremantle Application Manager doesn't offer any UI to install deb packages directly. This will be still possible via command line, which is a message probably clear enough for the non-advanced users.
Umm, these are the things I would have liked to be solved via blue/redpill modes in some way. Everything is turning kinda into - command line = redpill, UI = bluepill. Which is sort of understandable, but also bad because you're deepening the chasm between user and developer.
 
attila77 is offline attila77
2009-06-19 , 23:25
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#30
Originally Posted by zerojay View Post
This feels like a microcosm of Linux itself, doesn't it? Why isn't there just one distro of Linux? Why not ask them to shut down their forks? Everyone can get their packages from the same place, QA would all be simpler, user experience would be better, etc, etc... Well, some people just have different ways of doing things... or they just want to operate outside of the norm. Or they need to tweak things so that it runs better on their small embedded machines.
Hey, nobody is going to be going around with a large stick beating up pesky private repo holders... It's just that you have to be in the clear that a private repo is something far off the beaten path -> that's why it's better for the repo owners to be aware of a possible (collateral) isolation and be offered to migrate to extras (and to find out why they aren't there in the first place, and thus help figure out what's the extras repo potentially missing).

A personal example, there is aumix. I just can't understand how N810 users can live without it, and yet, it's only in the elkins.org repo and causing mayhem with packaging as it's in a chinook repo The original packager probably lost interest and left it for dead. If it was extras, it would be easy for someone to pick it up, but this way it's a
 

The Following 2 Users Say Thank You to attila77 For This Useful Post:
Reply
Page 3 of 8 12 3 45 Last »

Tags
maemo repos packages

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 15:56.

Contact Us - Home - Archive - Top