Announcing a Community Repository of packages for Mepis 7.0

[timkb4cq]

EDIT (by Adrian): I haven't heard from Tim in a long time and no updates have been made to the pool, I will assume that this project has been dropped or mothballed for now. Please remove this notice if that's not the case.


This is not the official Community Repository that you may have heard about.
That project has made some headway, but the lead of that project, the most able Allan Gabston-Howell has had his time occupied lately with far more important things.

Because a Community Repository is a tool I've wanted, I've decided to step up and make one happen anyway. When Allan has time to turn toward Mepis once more I would be delighted to have him finish setting up the structure he wanted and switch teharris.net over to being a mirror of the official Community Repository. In the long term, as people come & go a project like this needs the kind of structure Allan was looking at. But in the meantime this repo can be useful.

It currently consists of packages I have built plus some from Adrian TM and some packages from those package author's websites included for convenience.

To add this repository in Synaptic create a new entry with the following settings:

Binary (deb)
http://teharris.net/mepis/
7.0
main contrib non-free

The gpg key to add to your apt-key ring to avoid the "repository can't be authenticated" error can be downloaded here: http://teharris.net/files/Unofficial_Community_Repo.asc You may have to right click and select Save As to download it instead of viewing it.

To add the key to your apt keyring, su to get root privileges, then use the command:
apt-key add Unofficial_Community_Repo.asc

BTW, make sure you have updated before you add the key as the latest mepis-config update resets the list of trusted keys for apt-get and you'll just have to add it again.

The list of packages currently in the repo is:

basket 1.0.2
checkinstall 1.6.1-1
devede 3.6
gbonds 2.0.2
hwreport 0.9.4
kcheckgmail 0.5.7.4
Konq-Kim 0.9.4
kompozer 0.7.10
kooldock 0.4.7
pan 0.132
pidgin 2.3.1
pidgin-encryption 3.0
pidgin-guifications 2.14
pdfedit 0.3.2
sppedcrunch 0.9
wine 0.9.53
wlassistant 0.5.7-1

Obviously, I'd like to see this list expand.
If anybody has built a package for Mepis 7.0 that they like added to the repository, first check some guidelines at http://adrian.scribblewiki.com/Packaging_procedures and if you can meet them Private message me here, or email repo -at- teharris.net.

To request a new package or new version of a package, post the package name and version here: http://adrian.scribblewiki.com/Packa...ded_in_MEPIS_7

Enjoy!

[Adrian]

Thank you, one quick note, can you please update Wine to 0.9.53

[Jessminder]

thank you !

Great initiative! Just a question...why bothering packaging wine when they have their own repo?

Now, too bad that I am just a beginner in packaging otherwise I would be more than happy to help out in bringing more packages on-board.

[timkb4cq]

For convenience more than anything.

Most people don't want to add a dozen different repositories to their list. I know I don't. So I added their package to this repo (it IS the package from winehq). It's saves them bandwidth and removes the need to add that additional repo and then add the gpg key for it. Not to mention re-installing the the gpg key whenever an update to mepis-config rolls out.

And I did just update Wine to 0.9.53

[Farcry]

This repo is a great idea and I much appreciate your work in bringing it forward.

But what about the odd .deb created (inevitably with checkinstall) by lazy people like me, who would find it difficult to fulfil Adrian's requirements to be a proper 'package maintainer' or have insufficient experience to reliably create "proper" debs?

I've found some of these "illegitimate" debs created by others very useful, but I appreciate they won't have the same status as the properly structured ones in a community repo.

Would a "contributed in good faith" but "use at your own risk" section be appropriate in the repo?

(For example, I have a checkinstall deb of Grsync 0.6.1 for Mepis 7.0-32)

[Roadblock]

Good job!!

[timkb4cq]

The main problem with checkinstall debs is that there is no dependency checking so you can have a broken package without apt-get/Synaptic knowing about it or how to fix it. That's a no-no in a repository.

And not having a listed maintainer and a gpg signature for that maintainer is a security issue. One of Warren's biggest fears with the Community Repository is that an infected/rootkit/Trojan/whatever package could be introduced and cause Mepis users trouble (as well as bad publicity for Mepis).

I agree that those checkinstall debs are often quite useful (that's how I made my first debs) and you can always post them in the Forum here. I certainly don't want to discourage anybody from helping out the way you do.

But, unfortunately, I cannot add them to the repository without those issues being addressed. I have to minimize my potential liability by instituting reasonable measures to ensure the safety of the packages I host.

Originally Posted by Farcry

Would a "contributed in good faith" but "use at your own risk" section be appropriate in the repo?

I would say "no", unfortunately. Basically for two reasons, and both come down to the fact that checkinstall debs don't mandate dependencies.

1. It's too dangerous. While unlikely, it IS possible for a checkinstall deb to cause havoc that is hard to undo. An ordinary deb can too if the packager wasn't careful enough, but rather unlikely.
2. It can confuse people. Say someone create a .deb of something that requires a certain library (gnome specific libraries for example) that isn't installed by default. The .deb creates an entry in the Kmenu. What is a newbie going to do when the program refuses to launch and won't give an error message without the user having to resort to using a shell to see possible errors? And that is assuming the user knows the name of the binary (and where it's located in the cases when it's not placed in the path), which may not always be the case.

Originally Posted by timkb4cq

But, unfortunately, I cannot add them to the repository without those issues being addressed. I have to minimize my potential liability by instituting reasonable measures to ensure the safety of the packages I host.

You know, there's a question about creating .debs that you seem to be able to answer. Does it matter much when creating them how "clean" your system is? And by clean I mean: does everything on the computer used to compile and build the deb need to be purely etch if intended for Mepis or Etch?

The reason I ask is because I'm not sure if my upgraded libc6 (I'm using libc6 from Lenny, but everything else is Etch) would cause problems for others that may want to use a package I've put together (well, when I'm more comfortable in deb-building that is).