James Walker wrote:

On 26-Jul-06, at 7:06 PM, Larry Garfield wrote:

...

I recommend Debian upgrades its Drupal packages, too. I understand Sarge, but why does Sid include 4.5.x?

AFAIK, there isn't an active Debian maintainer for Drupal... killes?

Ok, here is it again, the long, sad story of the Drupal debian package... Once upon a time some guy named Hugo came along and asked "hey, I'd like to make a .deb from Drupal." and Dries, being nice, said "sure, why not?". Hugo kept producing Debian packages for two (?) more releases and then vanished from the face of the earth. Meanwhile, Drupal continued its fast race towards world domination. But there were still some people using the ill fated debian package and asked support questions. This annoyed me a great deal. So I spoke to my friend Hilko who after some time released a new debian package and kept doing that for a while. This Deban package of his is now in the stable debian release and people seem to see a need to add security fixes. Due to debian's procedures, the package in the stable release can't be upgraded to 4.7. Hilko doesn't really like PHP applications since he is a Perl coder, he also doesn't use Drupal himself. So he abandoned the package several weeks ago. There seem to be some people who want to take over as maintainers, but I really hope they find some better way to spend their spare time and let the package die. I repeat my opinion: Due to the faster release cycle, Drupal isn't something that should be part of a software distribution which has a long release cycle. Cheers, Gerhard

On 7/26/06, Larry Garfield <larry@garfieldtech.com> wrote:

On Wednesday 26 July 2006 20:50, Gerhard Killesreiter wrote:

...

I repeat my opinion: Due to the faster release cycle, Drupal isn't something that should be part of a software distribution which has a long release cycle.

I think what Gerhard is saying, and he has a point, is that under Debian when someone does apt-get upgrade, they expect that the package gets upgraded seemlessly the Debian Way. Since Drupal is a) fast moving, b) composed of core and myriad of contribs, c) has a web interface for install/update and not a command line one, it is difficult to have a proper Debian package that preserves the user's data integrity as well as keep them up to date with all the core and contrib they may have. Unless we have something that combines Adrian's new installer with sympal's command line scripts, we don't have something that can be useful in a Debian apt environemnt. Even if we do, there is still the issue of contrib and the fast pace of Drupal vs. the conservative nature of Debian.

...

is that under Debian when someone does apt-get upgrade, they expect that the package gets upgraded seemlessly the Debian Way.

While I have no interest in seeing a Debian package of Drupal I do think a Ubuntu Server package of Drupal on reliable 6 month release cycles is reasonable.

I am not using Debian myself, but use Ubuntu too for my servers (test and production).

Adrian is talking with Shuttleworth Foundation and we should be keeping an eye towards seeing Drupal as the CMS platform of choice for these kinds of foundations.

That is great.

From the technical point of view, solving it for Ubuntu is exactly the same as solving it for Debian, since Ubuntu is just a variant of Debian and rely on them as their upstream.

Whether Debian's policy allows newer pacakges to get in or not is beyond our control. Putting the package in the Ubuntu universe or multiverse repository may be all that is needed. Here is the Drupal package info for Ubuntu 6.06 LTS server. # apt-cache show drupal Package: drupal Priority: extra Section: universe/web Installed-Size: 1944 Maintainer: Hilko Bengen <bengen@debian.org> Architecture: all Version: 4.5.8-1 Depends: debconf (>= 1.2.0) | debconf-2.0, apache2 | httpd, php4-cli, libapache2-mod-php4 | libapache-mod-php4 | php4-cgi, php4-mysql | php4-pgsql, exim4 | mail-transport-agent, wwwconfig-common (>= 0.0.37), mysql-client | virtual-mysql-client | postgresql-client, makepasswd Recommends: mysql-server | postgresql Suggests: libapache-mod-ssl | apache-ssl Filename: pool/universe/d/drupal/drupal_4.5.8-1_all.deb Size: 488036 MD5sum: e2ede48b249e07b0d73a6c99082509e1 Description: fully-featured content management/discussion engine Drupal is a dynamic web site platform which allows an individual or community of users to publish, manage and organize a variety of content, Drupal integrates many popular features of content management systems, weblogs, collaborative tools and discussion-based community software into one easy-to-use package. . More information about is available at http://www.drupal.org Bugs: mailto:ubuntu-users@lists.ubuntu.com Origin: Ubuntu As you can see, it is 4.5.8 still. Way behind.

Op donderdag 27 juli 2006 04:49, schreef Khalid B:

Since Drupal is a) fast moving, b) composed of core and myriad of contribs, c) has a web interface for install/update and not a command line one, it  is difficult to have a proper Debian package that preserves the user's data integrity as well as keep them up to date with all the core and contrib they may have.

We are forgetting that a LOT of people (should) not want to keep up to date. Just ask yourselve this question about a system you are not as closed involved in as Drupal: "Am I really interested in the Very Latest Features of phpmyadmin?". My answer is no. If I (would*) use phpmyadmin I want three things: * It must Just Work (bugfree) * It must be secure. * It should meet my requirements (IE do what I need it for) If, in ten months from now a new debian comes available, and features a new PHPmyAdmin branch, i'll be happy, and probably use the new features gladly. But for now, I (would) run the most stable -acc to debian- version. And thatt one has worked fine for me all along: Why go trough all the hassle of New And Improved Features, concepts and all that, when the current system works? Would you really deploy MySQL 5 already? Only to get features you have been doing fine without for ages? We (Drupalleers) seem to forget that people might not be that much interested in our improvements, but want their website to continue running the coming years. And frankly, in my branch/niche/userbase, being middle and small companies with a need for "a website" aka brochureware, this is all people want. People see Drupal as a tool just like we see all other software as a tool. If you were happy with 4.6 by the time you released your site on it, why would you want to go to 4.7? Don't forget that continuation costs a certain price per month/year/week, but that upgrading requires big investments every time. If you have built a Drupal site for €9000 (which meets the requirements of the client) and within four months that client needs to invest another €5000, just to get New Stuff they never asked for in the first place, is IMO wrong. To summarise: There are a lot of valid reasons for a stable, yet oldish, reliable, yet not cutting edge, and know-what-to-expect yet not with the latest Schmupal, release system. The fact a 4.5* debian version is somehow maintained prooves this fact. Bèr * I dont actually use phpmyadmin, on my own debian server. But this was the closest and best example I can find.

On 27 Jul 2006, at 11:36 AM, Dries Buytaert wrote:

The .install files, the update script and the installer could take some burden of the package maintainers (but might need a command line extension so they can be hooked into their tools).

nothing is stopping you from running drupal on the command line. All you need to do is set some environment variables before you bootstrap. We need meta-data and dependency information before we can do that though. Now that we have modules in their own directories, that entire process can start up again. We also need to tackle individual module versioning. Each and every time a drupal.org module distribution package gets updated with any change whatsoever, a new version needs to be created. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

Am Donnerstag, 27. Juli 2006 17:22 schrieb Bèr Kessels:

.... this is what sympal scripts aims at. See here for a detailed list of what the 1.0 of these scripts should do: http://webschuur.com/node/637 (the commandline documentation) Access denied :/

Bèr

-- GPG/PGP - http://subkeys.pgp.net/ pub 1024D/E71CDBFE 2006-07-10 Stefan Auditor <sanduhrs@audiens.de> Fingerprint=E9C5 56E8 7A5B 92AD 548A 7B57 2106 BE82 E71C DBFE

Op donderdag 27 juli 2006 17:26, schreef Sanduhrs:

Am Donnerstag, 27. Juli 2006 17:22 schrieb Bèr Kessels:

...

.... this is what sympal scripts aims at. See here for a detailed list of what the 1.0 of these scripts should do: http://webschuur.com/node/637 (the commandline documentation)

Access denied :/

Sorry, I forgot to publish it for anon users when releasing it! Is now fixed http://webschuur.com/node/637 Bèr

On 28 Jul 2006, at 4:46 AM, Derek Wright wrote:

i can see why some people want to still support nightly snapshot builds/tarballs, but i don't think a) we should encourage their use on real sites, b) worry about how to handle those in installers/ real distributions, or c) delay having real version of contrib releases to get nightly snapshots working. if someone *really* wants the absolutely most recent code, they're probably a developer/ tester, and therefore, clueful enough to get the code from CVS. otherwise, they should be perfectly happy with the last real release that was bless and tagged by the maintainer on a given branch.

of course. but with a dependency system, a module should be able to depend on modulename > 4.7.34 || modulename >= head.2006.06.17 By not supporting some numbering for stuff in HEAD at the least, you make it impossible to actually test if the requirements are correctly met until a release is actually made of all packages in the dependency tree. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

Earl Miles wrote:

Adrian Rossouw wrote:

...

We also need to tackle individual module versioning. Each and every time a drupal.org module distribution package gets updated with any change whatsoever, a new version needs to be created.

Dear god no. Developers need to be able to control the version numbers

i suspect this is a semantics mismatch. Adrian is probably thinking of version number like Subversion thinks of version number. It always increases with every commit. A public release is a different axis. A version number can increment while a release number stays the same. We just need sensible words for these things.

On Thu, 2006-07-27 at 09:56 +0100, Neil McGovern wrote:

On Wed, Jul 26, 2006 at 09:25:27PM -0400, James Walker wrote:

...

AFAIK, there isn't an active Debian maintainer for Drupal... killes?

That would be me. I also produced the security update.

Further info on plans with regard to drupal can be found at http://lists.alioth.debian.org/pipermail/pkg-drupal-devel/2006-July/000005.h...

Sid should include 4.7.2 shortly, which should propogate to etch in time for the release, and I intend to remove the 2.5 packages as soon as possible.

I'm personally of the opinion that php apps shouldn't generally be packaged by distros because of the upgrade issues and the fact that it isn't really a compiled binary aka not dependent on the rest of the distributions libraries. But splitting the packages by version and letting the distro's users deal with the upgrade path seems like a good idea.