R&D framework funding
See www.apocketfullofeuros.com for an unofficial guide to EU R&D framework funding
Adding debian/rules unpack as a required operation
A suggestion for policy: If a package source does not come fully unpacked - i.e. it uses a DBS-like system - debian/rules must include an unpack target, that unpacks the source code and applies all patches to it. The motivation is, that I'm tired of wanting to look at the source code to a program, and discovering it's in some DBS-like system, and I don't have the foggest how to unpack it, short of running a build and killing the build, or manually (wherein it can be hard to tell what patches are applied in what order.) debian/rules unpack exists in some DBS-like packages, and is the simpliest solution, IMO. Comments? -- David Starner - [EMAIL PROTECTED], dvdeug/jabber.com (Jabber) Pointless website: http://dvdeug.dhis.org When the aliens come, when the deathrays hum, when the bombers bomb, we'll still be freakin' friends. - "Freakin' Friends"
Summary of KDE filesystem discussion
Hi, May I try to summarize the filesystem discussion on KDE list and suggest that it will continue in debian-policy? * Many people feel that KDE (and Gnome) is too large a whole to be stuffed in /usr/bin, /usr/share etc and would deserve a separate directory like X * Some proposed using /opt/kde3. Arguments: + Other distributions work like this, and better compatibility with them could be beneficial + FSH seems to permit this (possible misunderstandings about phrase 'add-on package' in it)... - ...but Debian policy apparently does not. - /usr is deliberately placed on another (large) partition on many computers and changing KDE to /opt could ruin this optimization - Changing from /usr to /opt could surprise and confuse seasoned Debian users who remember the policy in their dreams.. * Classifying applications to KDE and just "generic Qt" apps could be difficult and so deciding if something should go under KDE-dir or some else could be difficult * The debate got quite emotional (which seemingly often happens when discussing the policy?-) - Jarno -- Learn Finnish! "Epäjärjestelmällistyttämättömyydellisyydellänsäkäänköhän?" = "Not even with his or her own ability or property of not making other people to make things unorganized, I wonder?"
Re: Summary of KDE filesystem discussion
Hi - again, I already requested comments for the following filesystem layout on the KDE list but I guess this list is a bit more appropriate for the subject. Now that I've thought a bit more about it, I think this possibly could work with ordinary symlinks, too, and moving to the new layout would not mess up previous installations too badly. I'm still not proposing it to be implemented to Debian (don't think I'm in a position to do that anyway), but would like to have some generic discussion on wether it could be possible to renew the filesystem layout in the future and especially to make it more suitable for "ordinary users" and desktop environments? So, here goes the original mail: --- clip --- Just as a side note (NOT as a proposition by any means!): what's really so wrong in C:\program files style? Of course, on open systems, instead of vendor specific directories, there should be some other subdirectory policy (lsm for example?). If there were a way to remove symlinks when the original file is removed, I think the following structure would be the easiest to understand and administrate: + usr + bin + qtcups -> ../qtcups/bin/qtcups + nano -> ../nano/bin/nano + sbin + traceroute -> ../traceroute/bin/traceroute + qtcups + etc (conf) + share (data) + bin (binaries) + doc (man, info) + nano + etc + bin + doc + traceroute + etc + bin + doc ...or even: + kde -> kde2.2 + kde2.2 + kmail + konqueror + kde3 + kmail + konqueror + bin + kmail -> ../kde/kmail/bin/kmail ...or EVEN: + usr + X11R6 + kde -> kde2.2 + kde2.2 ... Then, you could easily try different versions and remove whole packages manually without having to guess where their may have installed their binaries, libraries, configuration files, data, documents etc etc. Of course, this is pure fantasy since there are no "2-way links". If there were, however, this model could well be made reasonably backwards compatile. Does it make any sense? I.e. have I missed some important aspect of Unix here? - Jarno
Re: Summary of KDE filesystem discussion
Jarno Elonen <[EMAIL PROTECTED]> cum veritate scripsit: > Does it make any sense? I.e. have I missed some important aspect of Unix > here? I think you are going backwards in time somewhat. That's the past, and the current trend is to move away from such setup, and some people thought it is even better to remove /usr entirely. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Re: Adding debian/rules unpack as a required operation
On Wed, Jan 16, 2002 at 02:25:36PM -0600, David Starner wrote: > If a package source does not come fully unpacked - i.e. it uses a > DBS-like system - debian/rules must include an unpack target, that > unpacks the source code and applies all patches to it. Make it another optional target listed in section 5.2 (slightly different from what you said), with a description along the lines of "Unpacks, patches, or otherwise generates all source files which are invariant across all builds" (this needs to be reworded). This is more generic, but excludes operations like "./configure" - ie, an 'unpack'ed source tree could be freely copied or shared between hosts without having to unpack it again. > The motivation is, that I'm tired of wanting to look at the source code > to a program, and discovering it's in some DBS-like system, and I don't > have the foggest how to unpack it, short of running a build and killing > the build, or manually (wherein it can be hard to tell what patches are > applied in what order.) debian/rules unpack exists in some DBS-like > packages, and is the simpliest solution, IMO. Comments? Seems at least as valuable as the "get-orig-source" optional target, probably more so. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpQxsn356KoJ.pgp Description: PGP signature
Re: Summary of KDE filesystem discussion
On Wed, Jan 16, 2002 at 11:19:25PM +0200, Jarno Elonen wrote: > Hi, > > May I try to summarize the filesystem discussion on KDE list and suggest that > it will continue in debian-policy? > > * Many people feel that KDE (and Gnome) is too large >a whole to be stuffed in /usr/bin, /usr/share etc >and would deserve a separate directory like X Interesting. > * Some proposed using /opt/kde3. Arguments: Not as a Debian package. /opt is for third-party software. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Adding debian/rules unpack as a required operation
hi :) On Wed, Jan 16, 2002 at 02:25:36PM -0600, David Starner wrote: > If a package source does not come fully unpacked - i.e. it uses a > DBS-like system - debian/rules must include an unpack target, that > unpacks the source code and applies all patches to it. i think this is the wrong approach there should be a standard tool which can cope with dbs packages, preferable this support should be build into dpkg-source. otherwise you would have to run code from the package, just to be able to view the package! not nice (okok, i could have a look at debian/rules first, but that's rather ugly if i have to check all included makefiles just to be able to look up some debian patch) (and yes, i have to trust debian packages anyway, as binary packages are root on my system, but i want to look at third-party source-packages without running code in them) there is a 'dbs' package in debian, doesn't it include such an unpack utility? -- CU, / Friedrich-Alexander University Erlangen, Germany Martin Waitz// [Tali on IRCnet] [tali.home.pages.de] _ __/// - - - - - - - - - - - - - - - - - - - - /// dies ist eine manuell generierte mail, sie beinhaltet// tippfehler und ist auch ohne grossbuchstaben gueltig. / - Wer bereit ist, grundlegende Freiheiten aufzugeben, um sich kurzfristige Sicherheit zu verschaffen, der hat weder Freiheit noch Sicherheit verdient. Benjamin Franklin (1706 - 1790) pgpxsHWWhOKQW.pgp Description: PGP signature
Re: Summary of KDE filesystem discussion
Previously Jarno Elonen wrote: > * Many people feel that KDE (and Gnome) is too large >a whole to be stuffed in /usr/bin, /usr/share etc >and would deserve a separate directory like X Define many. I also don't see what the advantage would be of moving it to a seperate directory. Without knowing what the actual problem is I don't see a reason for making any changes. > * Some proposed using /opt/kde3. Arguments: > >+ Other distributions work like this, and better > compatibility with them could be beneficial Incorrect, other distributions do not work like this. >+ FSH seems to permit this (possible > misunderstandings about phrase 'add-on package' > in it)... FHS does not allow it, /opt is for third party software which KDE and GNOME are not if the distribution contains them. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
