Main index > Off the wall > installation directories

By falcon_za (User), on Fri Mar 18 15:32:13 2005: installation directories.

I have a suggestion for a change in the future versions, since I think I have a better idea than what's currently done. If people find it dumb, or something I didn't think about makes it hard to implement, i won't cry, I promisse. But I like adeslets even more with it.

For the moment, the core part of adesklets goes to /usr/...., while all the desklets, and their configuration files, go to a folder in your homedir (typicaly .desklets), and the file remembering where are your desklets is ~/.adesklets.

for the core parts, that's fine. but for the individual desklets, I am not satsified with this solution, for two main reasons:

* if you have several users using a desklet, you have to copy it in each user's home. which is not really elegant, and a waste of space

* this way of installing the desklets make it impossible/hard to manage the individual desklets by some (most? all?) distros's package management system. On my gentoo for example, i would love to use "emerge --search adesklet" to find all the possible desklets, and "emerge adesklet-yab" to install it. But I can't think of any package management system who can install things in users' home dir.

Here is my suggesion to achieve this:

Quote:


I
The current "~/.adesklets" file should be moved to "~/.adesklests/adesklets.conf"

II
Each desklet's "config.txt" shouldn't be located in the desklet's own folder, but in ""~/.adeklets/deskletname/config.txt"", wherever the desklet's python file is located. It allows desklets to have their a folder per user where they can write their config file, plus whatever other file they'd like to create.

We need to think a bit more about here because of the config.txt file and the possibility to run several versions of the same desklet at the same time (but is there really a need for that?), and more seriously because of desklets upgrades.

If differents versions of the same desklets have the same options, it works without problems. new versions of the desklet automaticaly pick up the config of the version they replace, and everything is fine.

But this will not always be the case. the easiest solution is to use "~/.adesklets/deskletname-version/" instead of "~/.adesklets/deskletname/" this will handle perfectly different desklets versions running at the same time, and will handle updates no bug. the user will just have to copy his config file to the new directory after an update if the files are compatible, or create a new one if they are not.

To allow desklets of different versions to use the same config file, we need the following things (i don't know if they are already true, or if this would require modifying adesklets):

1) while reading a config file, adesklet should not care if two differents id containt different parameters.
=> distinct id in the config can be associated with different versions of a desklet. The current ~/.adesklets associate each desklet instance with an id. it would continue to do so, not having to care whether two instances are of the same version or not

2) parameters not understood by a given desklet in a given version should be ignored, and parameters missing sould be added (with the default value) in the same id.
=> upgrades (or downgrades, for that matter) can use the same config id, without complaining (crasshing?) because the config parameters available don't fit exactly what they expect.
I am not completely sure if this is to be handled by adesklets, or by the desklets themselves, having not read the code. But as far as the designs permits it, it should go to adesklets, and be totaly transparent to the desklet.

3) parameters' value not understood by a given desklet version should be replaced by a default value.
=> same advantage as above
this is obviously to be handled by individual desklets, but a minor one.



III
Make it a rule that the desklet must be able to run in a read-only directory (no file creation / deletion / renaming in its folder) and with all in files in this folder read-only too (no self-modification of the .py and associated files), because root will be the owner if it is installed under /usr, but the desklet will still have to be run by a normal user, not root.

I think (but then, i haven't checked in details) that this wouldn't go against any current desklet, so the sooner it gets in the doc, the less things will have to be fixed later.

If this was done, this would allow a cleaner (IMHO) install of the desklets, even when done manualy. A user with no root privilege could still put it somewhere in its home folder, but the sys admin could decide to install it in a central place, and make it available to all users.

More over, I could allow inclusion of individual desklets in packages managers (as portage in gentoo), letting them automaticaly install the desklet where it belongs in this given linux distro. I would love to be able to install desklets trough gentoo's portage system, since:
1) it can install/update/uninstall packages cleanly
2) it can handle dependencies (for example a cpumon has one)
3) it is the way any software should be installed on a gentoo box

I think that's all. Any opinion from other users? How about the developpers?

I don't think those modifications are difficult to make, and I think it would improve adesklets significanlty, on a sysadmin point of view.

If every body agrees that this is wonderfull, and the developper(s) agree to give us just this, then I'll be glad.

But if the devs don't want to do it, even though they agree it would be nice, maybe it is the opportunity i wanted to practice python, and I'll try to do it myself, and submit my modifs once they are done. but being a beginner in python, and not having read yet the code of adesklets, I wouldn't be very efficient.

By syfou (Core Developer & Desklet Author), on Fri Mar 18 17:29:30 2005.

Falcon_za,

I have been a UNIX sysadmin for a couple of years, and I do not think this to be a good idea. Allow me to share my views:

Quote:


if you have several users using a desklet, you have to copy it in each user's home. which is not really elegant, and a waste of space


I see the point, but good desklets should be fairly small. weatherforecast, for instance, is far too big to my taste. But read below.

Quote:


this way of installing the desklets make it impossible/hard to manage the individual desklets by some (most? all?) distros's package management system. [...] Here is my suggesion to achieve this: [...]

You see, this is exactly what makes me run away of many packages: mandatory, artificial infrastructure. The method you propose is fine by itself and (almost) functionnal, but yet enforce an policy on desklets configuration, making something purely optional (usage of the ConfigFile class or similar) becoming mandatory. Right now, all a desklet writer have to care about is being self-coherent. With this, you force him to use hooks he maybe wouldn't have cared about normally - and you also add a potential portability/ future development burden - read below.

Quote:


The current "~/.adesklets" file should be moved to "~/.adesklests/adesklets.conf"


That's the only point that is marginally wrong with your implementation proposal. As you know, for performance sake, adesklets does not use a central daemon. This means it needs a way to dynamically alter its main configuration file ($HOME/.adesklets) without conflicting with other running instances of the interpreter (written in C, incidentally). For doing so, it uses fcntl file locks on the file. Moving the file from $HOME/.adesklets to $HOME/.adesklets/adesklets.conf introduce many possible races conditions, especially if $HOME is mounted over NFS (speaking of system administration :-) ). For instance, we would have no way to atomically create a $HOME/.adesklets directory and grab the configuration file at the same time, and so on, and so forth... It would also somehow break backward compatibility, but that's a minor concern.

Quote:


Each desklet's "config.txt" shouldn't be located in the desklet's own folder, but in ""~/.adeklets/deskletname/config.txt"", wherever the desklet's python file is located. It allows desklets to have their a folder per user where they can write their config file, plus whatever other file they'd like to create.
[...]
Make it a rule that the desklet must be able to run in a read-only directory (no file creation / deletion / renaming in its folder) and with all in files in this folder read-only too (no self-modification of the .py and associated files), because root will be the owner if it is installed under /usr, but the desklet will still have to be run by a normal user, not root.


Well, it looks like what you are really looking for are symbolic links. A general, portable, well understood facility that make the behavior you are seeking entirely possible without a single change to adesklets. You could very well install desklets in any accessible place of your system, then just populate appropriately your home. Cruedly, on a GNU system, this would look like,:

Code:


cd $HOME/final/path/to/desklet
find /path/to/desklet -maxdepth 1 -mindepth 1 | sed 's/.*\/\(.*\)/& \1/' | xargs --max-lines=1 ln -s


And nothing would prevent you to use your favorite package manager to install desklets with it, provided appropriate packages would exist, which I have no intent whatsoever to do by myself, as reviewing, packaging, publishing operations already take a significant part of my time on adesklets (about 7 hours out of 20 a week right now).

Regards,

By falcon_za (User), on Sat Mar 19 03:03:05 2005.

Sylvain,

Here is my view on your view.

Quote:


I have been a UNIX sysadmin for a couple of years.


I haven't, so I'll consider your opinion wiser than mine "by default". Still, I might disagree from time to time.:)

Quote:


I see the point, but good desklets should be fairly small. weatherforecast, for instance, is far too big to my taste.

I looks a bit fat to me too, but it's ok. I am not going to complain that a themable desklet giving good functionality is a bit big. Afterall, I saved a lot of disk space by using adesklets compared to karamba or gdesklets, which have huge dependecies.

Quote:


You see, this is exactly what makes me run away of many packages: mandatory, artificial infrastructure.

As far as gentoo is consered, infrastructure is not so mandatory. There are recomanded places to install software, but it is still rather flexible, and can basicaly install anywhere the package manager see fit. The only problem is that the package manager can't put it in your home dir, because, well, there is just no way the package manager can know where your home dir is, moreover, to how many homedir it should install.

Quote:

The method you propose [...] enforce an policy on desklets configuration, making something purely optional (usage of the ConfigFile class or similar) becoming mandatory. Right now, all a desklet writer have to care about is being self-coherent. With this, you force him to use hooks he maybe wouldn't have cared about normally.


I am aware that my method introduces some constraints on the way you should program. I just think, that those constraints are "worth it". Either using the config class, or finding and writing by myself in the home dir doesn't sound so hard to be. But I have to agree that this is entirely subjective, and that others may see it differently. And since I haven't writen any desklets (yet?), my view doesn't count so much. I'll still continue discussing my ideas, for the sake of the argument, and because I am stuborn.

Quote:

Quote:


The current "~/.adesklets" file should be moved to "~/.adesklests/adesklets.conf"

That's the only point that is marginally wrong with your implementation proposal. [...]

Oh, I didn't realise this may cause problems. let it where it is now then. and rename the folder where i wanted to the other files as .desklets to avoid conflicts. Or is it still the same problem? I know nothing about nfs, so I din't get what was wrong. But seeing how many programs store their config file either in ~/.progName or ~/.progName/*, I didn't imagine it could be an issue. And i still don't really understand why. but then again, it might just be my lack of knowledge about nfs.

Quote:

It would also somehow break backward compatibility, but that's a minor concern.

Agreed. And I would add that if it is to be changed, the sooner you change it, the more minor this concern will be.

Quote:

Quote:


[...]

Well, it looks like what you are really looking for are symbolic links. A general, portable, well understood facility that make the behavior you are seeking entirely possible without a single change to adesklets. You could very well install desklets in any accessible place of your system, then just populate appropriately your home. Cruedly, on a GNU system, this would look like,:

Code:


cd $HOME/final/path/to/desklet
find /path/to/desklet -maxdepth 1 -mindepth 1 | sed 's/.*\/\(.*\)/& \1/' | xargs --max-lines=1 ln -s



Hmm. This would certainly do the trick. Still have to be sure that the script does not self-modify its own file, but that shouldn't be a common programming style, so no real worries.
This would be functional, but it doesn't fit my esthetical point of view. I like when unix programs can be install anywhere (to let me put them under /usr), when store their configuration under /etc if the config is common to all users, and under ~/ if it is user specific. in etc and ~, either only have one file, or group everything under one dir.

But agreed, this is more about esthetics than anything else. Since you are making the programm, you chose. And I certainly don't think this would be worth a fork, so if you don't like my way, I'll teach myself to like your way.

Quote:

And nothing would prevent you to use your favorite package manager to install desklets with it, provided appropriate packages would exist, which I have no intent whatsoever to do by myself, as reviewing, packaging, publishing operations already take a significant part of my time on adesklets (about 7 hours out of 20 a week right now).


Care for some help? I wanted to teach myself how to make ebuilds (gentoo package). Why not try it on desklets? Btw, is the ebuild for adesklets your work, or a contribution?

By syfou (Core Developer & Desklet Author), on Sat Mar 19 04:15:43 2005.

Hi again Falcon_za,

Quote:


I am not going to complain that a themable desklet giving good functionality is a bit big.

Oh, me neither... But most of this space is occupied by three full icon sets - including one and telling people how to get the rest would have been better in my mind...

Quote:


As far as gentoo is consered, infrastructure is not so mandatory. There are recomanded places to install software, but it is still rather flexible, and can basicaly install anywhere the package manager see fit. The only problem is that the package manager can't put it in your home dir, because, well, there is just no way the package manager can know where your home dir is, moreover, to how many homedir it should install.


I was refering to the infractucture your proposal would enforce, not to the platform's structuration...

Quote:


Either using the config class, or finding and writing by myself in the home dir doesn't sound so hard to be.

You are right, it is not, but it is an order of magniture more error prone than just accessing files in current working directory... Trust me on this. Besides, there are other maintenance/high-level portability problems with this I did not bother explaining here.

Quote:

I know nothing about nfs, so I din't get what was wrong. But seeing how many programs store their config file either in ~/.progName or ~/.progName/*, I didn't imagine it could be an issue. And i still don't really understand why. but then again, it might just be my lack of knowledge about nfs.


Problem is not nfs related, as nfs only make things more apparent. There is nothing wrong having configuration directory the way you describe them - it is even good UNIX practice nowadays - it is only that the adesklets interpreter need to grab a lock on its configuration file, and that there is a few atomicity-related problems with having files we want to lock in potentially non-existing directories.

Quote:


Hmm. This would certainly do the trick. Still have to be sure that the script does not self-modify its own file, but that shouldn't be a common programming style, so no real worries.


Well, that's not a concern specific to symlinks. As long as we accept installing things in place where people ca write, this can happen.

Quote:


This would be functional, but it doesn't fit my esthetical point of view. I like when unix programs can be install anywhere (to let me put them under /usr), when store their configuration under /etc if the config is common to all users, and under ~/ if it is user specific. in etc and ~, either only have one file, or group everything under one dir.


That's a really "linux-centric" way of seeing things :-) If you have time, I suggest you take a good look at the Filesystem Hierarchy Standard; things like desklets are somewhat in a grey zone, but according to the general spirit, it should probably be kept together in a single directory like /usr/share/adesklets or something similar. Symlinking to it is only a natural approach from there.

Quote:


Care for some help? I wanted to teach myself how to make ebuilds (gentoo package). Why not try it on desklets?

Sure, feel free to go ahead... But I am affraid you will not be learning much things by packaging mere desklets as this is certainly tedious, but still fairly trivial.

Quote:


Btw, is the ebuild for adesklets your work, or a contribution?

It was mine. Regards,

By falcon_za (User), on Sat Mar 19 06:05:41 2005.

Hi again,

syfou wrote:


That's a really "linux-centric" way of seeing things :-) If you have time, I suggest you take a good look at the Filesystem Hierarchy Standard; things like desklets are somewhat in a grey zone, but according to the general spirit, it should probably be kept together in a single directory like /usr/share/adesklets or something similar. Symlinking to it is only a natural approach from there.


My adesklet is in /usr/share/adesklets. and I planned to install all the desklets in /usr/share/adesklets/desklets/ or something like this.
I Just hope(d) there was a way of putting them there, running them without any need to simlink, and still have the config file in my home dir. But, sure, simlinking isn't that bad, and I guess that's what I'll do from now on.

Quote:

Quote:


Care for some help? I wanted to teach myself how to make ebuilds (gentoo package). Why not try it on desklets?

Sure, feel free to go ahead... But I am affraid you will not be learning much things by packaging mere desklets as this is certainly tedious, but still fairly trivial.


Well I'll try, and if i find it too tedious and not intersting enough, i'll just give up. And if I don't give up you'll end up with ebuilds.

Regards

By syfou (Core Developer & Desklet Author), on Sat Mar 19 12:24:29 2005.

Hi,

Quote:


I Just hope(d) there was a way of putting them there, running them without any need to simlink, and still have the config file in my home dir. But, sure, simlinking isn't that bad, and I guess that's what I'll do from now on.

Well, as long as you want to run a desklet on you desktop, you'll have to perform some "manual" steps anyway besides installation under $pkgdatadir/desklets - finding the desklet, run it then configure it, so it will never be a completely automated process.

This said, if you need more automation, we could work together to provide some portable script for automated 'local' (i.e. in $HOME) installation that would go though what's in $pgkdatadir/desklets and populate a symlink tree accordingly somewhere under $HOME... It could easily be distributed along the base package or with your ebuilds...

By syfou (Core Developer & Desklet Author), on Sat Mar 19 13:24:24 2005.

Hi again,

I just though a little while about that, and I don't think ebuilds are the best way to go for this, because the whole submission process can be quite long: that's a level more of indirection, and I think that users will not want to wait two weeks before trying out a new desklet when it comes out. Besides, ebuilds are gentoo specific, and actual structuration of desklets is so simple that portage is really not required for easy uninstall.

But, as you probably now, desklets have an atom feed. This is quite easy to parse (in fact I wrote a parser myself, see the quidnovi desklet), and it contains up to date information on all 'official' desklets, including downloads: it would be nice to leverage on this infrastructure... I can quite imagine a python script that would reuse, interactively or not, this information to fetch and install desklets, as an unprivileged user or as root, maybe even taking care of "local-style" installs as described above... This could be included in the core adesklets package. But let me know what you think.

By falcon_za (User), on Sun Mar 20 09:26:49 2005.

I agree that ebuilds's problem is that sumbition is far too slow, especialy now when the adesklet project is very active, with new things happening much faster than ebuild submission can handle.

What you suggest would in the end, probably do something similar to firefox and its extentions. something integrated to the main software able to manage updates, and to show you the available options.

On an opperating system without any centralized update system (windows?), it's great, because it basicaly makes your life easier to keep up to date.

But on a system like gentoo, debian, *BSD, archlinux, and the like, it doesn't feel like it makes your life easier. I have a central update/install/uninstall system and i want to use it. I like to be able to update my whole system in one step. i like to remove things i don't want anymore through it, and let it automaticaly find out and remove unneeded dependecies. and those dependencies were also equaly installed without any need to think about them. And some times, when I don't realy remember what is installed on my system, and i want to know if there is something I can throw away, i have only one central place to look at.

This is obvious to say, but if the number of software not fitting in this rule grow (currently, I only have firefox behaving this way), it basicaly means that updating is not one step, but 1+n steps, n being the number of software not fitting into this rule.

I think that after a while, adesklets is likely evolve slower. Now it is a nice a new project. I guess it will trun to be a nice and mature project. which means improvements to the code will become slower (most main things easily changed will be already done), and same goes for the desklets depending on it, and most usual desklets will be covered (thus not too many new desklets all the time). then the slow submission process of ebuild won't be that much of a problem. and then it is possible to take advantage of them as a central system. and as the userbase grow, people (desklets developpers using something else as gentoo?) will show up by them self to make the pakaging for their favorite system.

So I don't think I is a good idea to spend time to develop a internal update and installation system, because that time will be wasted when later people switch to a OS central packaging system, and moreover, it could hinder the will to make such pakages, even though they would be a better solution.

So the remaining question is: what kind of packaging provide for the moment?
I see two options:
1) no packaging at all. focus on developpement, you'll take care of packaging later, when developpement takes less time because the project matures, or if someone show up to do it for you.

2) if it takes a reasonable amount of time, make the package system for one distro, either the one you use or the one you know to have the largest adesklets user base. even if they are not integrated in the central repository. If we take gentoo for example, I could very well manualy copy the ebuilds to my portage overlay, until they are officialy accepted.
Even if this solution is not 100% automatic, it sounds better to me than a separate update/ install system because:
* transition to the central system will be easy
* it can manage dependecies resolution in the way i am used to
* though it is one step more than if it was fully intergrated in portage, it is still the same number of steps as an adesklet specific install system.


In my oppinon the atom feed, and its quidnovi is a good thing, even with a central update system, to keep informed of new desklets one might want to try. And until the ebuilds are integrated in portage, it is also usefull to know when it is time to put new ones in my portage overlay.

just my $0.02

By syfou (Core Developer & Desklet Author), on Sun Mar 20 15:46:19 2005.

After reflection, I agree with you there... This would be a bad idea to circumvent portage, or any generic source installer somebody have on his system. No reason for me to impose new artificial infrastructure when others exist: why coudn't I have a taste of my own medecine? :mrgreen:

A third option I received for "packaging" would be to keep around a single tarball of all desklets, but I do not really like it either (Would this qualify as packaging anyway?)... From a choice and customization point of view, this would not be good... Not speaking of ressources usage, since the tarball could become very big.

But that doesn't solve our problem, does it? For my part, I do not think building and submitting ebuilds (or any other build system packaging meta-information, but gentoo is actually the biggest user pool as far as I know) will serve other purposes than somewhat helping gentoo end-users (which is already good, incidentally). Other distro manager will simply not use them, because they would be so simple they probably will not have any reusable part in other packaging system beside their name, version and download points, three information that will be available anyway by directly pooling adesklets web site/atom feed. And I am not sure about the 'stabilisation' factor you talk about... What you say is pretty true for the core interpreter, they will be a time when updates will hopefully become a lot less frequent, but is this the same thing about desklets? Not if by any chance adesklets follow the same trend as other softwares in the same niche: GKrellM for instance still get new/updated plugins all the time (look here).

So what we look here into is not a purely technical issue, but more a managerial, human factor: who will have the pugnacity needed to submit and maintain all those ebuilds or misc. package information persistently over time? I know I do not. Making them once is an easy job - I could have done this in less than an hour and walk away. Submitting them once it tedious and error prone (not real possible automation here I know of if you are not an accredited gentoo developper), but still short. At max. an afternon and it would be over with. But doing it day by day, answering questions, making follow-ups, updating thigns as needed? That's a real commitment, and I have no time for this: that's why I produced an atom feed out of a good suggestion I was given on the adesklets-devel mailing list. At least I have peace of mind concerning this, since all users can stay informed.

Someone who would be willing too take such a commitment should probably be a gentoo developper with write access to the tree (or take the necessary step of becoming one), as It would make things significanly easier... And we are not there yet. This person would probably also automate desklets ebuild production somehow: I know I would...

[EDIT]
Here is a small script that I would probably use as a base if I had to maintain desklets package for any system. Highlighted html version here, original source there.

By CitizenX (Themer / Graphic Artist), on Sun Mar 20 18:18:00 2005.

What will most likely result is a dual-packaging system, like gdesklets has. You can go to their site and get new desklets, up to date, and simply drag the url into the gdesklet manager, and it installs. Portage doesnt keep track of these desklets, but gdesklet will. Portage also has desklets available as ebuilds, but some can be a little behind. The plus to this is that if you uninstall gdesklets, the desklets themselves come out as well...I dont know if thats the case when you emerge -C gdesklets-core with manually installed desklets.

I view desklets as part of gdesklets, not as separate programs to be installed...i just put new functionality into gdesklets when i need it. I don't see any need to produce individual adesklets as ebuilds unless there becomes an overwhelming demand for it...in which case we'd need a maintainer.

I put all my desklets into ~/.desklets ....if I need to update, I go to the website and update. Of course, with the directory scheme i see in most desklets, this results in multiple copies of each desklet....thats simply up to me to delete old directories when I upgrade or (not likely) uninstall. It's the same with ebuilds...let the ebuild install the core interpreter, not the desklets. I'd suggest a notification in the ebuild on how to get desklets...but not include more ebuilds that could take forever to get updated.

By falcon_za (User), on Mon Mar 21 00:53:31 2005.

now I am all excited by this new program adesklet is. So I don't mind regularly coming to see what's up, or reading an atom feed to see if i need to update. but after a while, unless i start to develop, i will just want to use them, and not think about it. Still, if there is an update to a desklet I use, I'd like to get it. portage can help me on this.

but to me, the BIG seller point for integration to portage is dependencies. We already have one desklet with a dependency, and I expect this to grow in the future. I don't want to remember which library I installed for which desklet. once I remove a no longer needed desklet, I want portage to be able to remove uneeded dependecies.

Having a look at gdesklets is a good example. I saw some gdesklets I wanted on the web site, so I downloaded it. But it wouldn't run, since it needed theming elements provided by another desklet. then download the other one (after having a hard time finding which one it was, since it was not clearly said). Still not working. dependecies on some engine, one more similar step, and I got bored, and unistalled gdesklets. I don't want this to happen to adesklet, so I think dependecy resolution is a must, and I don't see the point in developping a clone to portage to integrate in adesklets, while we have portage.

I agree that what we need is a gentoo dev to act as a package maintainer. adesklet is still a new thing but i guess that after a (short?) while, a lot of people will be using it. which might include devs, and hopefully one of them will agree to do it.

By syfou (Core Developer & Desklet Author), on Mon Mar 21 02:55:06 2005.

falcon_za wrote:


Still not working. dependecies on some engine, one more similar step, and I got bored, and unistalled gdesklets. I don't want this to happen to adesklet, so I think dependecy resolution is a must.

Have you seen this report? adesklets is far from gDesklets current situation.

falcon_za wrote:


I don't see the point in developping a clone to portage to integrate in adesklets, while we have portage.


"We" is a faily restrictive word here... Gentoo is not the world, even for adesklets. While I agree with your take on this, I hope you understand why I cannot manage this myself -- my time is best spent elsewhere on this project, and none if my desklets use anything that is not part of core Python - I did my homework on this.

And about your initial concern about system-wide installation, I will keep my solution (which is how I planned to make things in the first place), because of its simplicity.

But enough said. Now let's work. :-)

By falcon_za (User), on Mon Mar 21 03:24:32 2005.

syfou wrote:


falcon_za wrote:


I don't see the point in developping a clone to portage to integrate in adesklets, while we have portage

"We" is a faily restrictive word here... Gentoo is not the world, even for adesklets.


Sure, I was a bit fast on this one. I meant : we have portage or ports or apt-get or pacman or... Well, just that making a separate package system would make things harder for people who chose a distro with good package management, and make it easier for those who have one which doesn't. People are free to chose their distro, so if they want package management, they can chose one that is capable. and if they are not the admin, your design alows them to put it the home dir.

But anyway, we agree on that, so no need to keep arguing.

Quote:

While I agree with your take on this, I hope you understand why I cannot manage this myself -- my time is best spent elsewhere on this project, and none if my desklets use anything that is not part of core Python - I did my homework on this.


I agree with that. To me, your time is far more valuable on something else than packaging. I just want to point out that if you ever decide to actualy do some packaging, do it for existing package system(s), and don't try to make your own.
Maybe I'll post on gentoo's forum to ask if there is any dev around willing to do it.

Quote:

And about your initial concern about system-wide installation, I will keep my solution (which is how I planned to make things in the first place), because of its simplicity.

Got it. I can live with it. especialy since you pointed out the simlink way of doing things.

adesklets is proud to be hosted on:

SourceForge.net Logo

Back to adesklets.sf.net.