Please remove the wget code from src_unpack and move the files to SRC_URI so that they can be pre-downloaded with emerge -f and portage can verify the authenticity of downloaded files. drupal-4.5.2 [...] wget http://www.drupal.org/files/projects/bbcode-${MOD_PV}.tar.gz tar xfz bbcode-${MOD_PV}.tar.gz einfo "Unpacking blogroll" wget http://www.drupal.org/files/projects/blogroll-${MOD_PV}.tar.gz tar xfz blogroll-${MOD_PV}.tar.gz einfo "Unpacking bookreview" wget http://www.drupal.org/files/projects/bookreview-${MOD_PV}.tar.gz tar xfz bookreview-${MOD_PV}.tar.gz einfo "Unpacking bookmarks" [...] drupal-4.6.2 [...] for item in `cat ${FILESDIR}/${MY_PV}/$i`; do einfo "Unpacking $item" wget -q http://www.drupal.org/files/projects/$item-${MY_PV}.tar.gz tar xfz $item-${MY_PV}.tar.gz done [...]
Reference bug #89125 You will notice that the modules simply cannot be put into portage because upstream uploads and updates packages without changing version numbers. Regards Lim Swee Tat
then you have to do one of the following: keep the digests up-to-date yourself and put in RESTRICT=mirror complain to upstream about their poor packaging habits rename the tarballs with custom stamps and put those into SRC_URI / gentoo mirrors
Moved the calls to pkg_config. Does this solve everyone's issue? I prefer not to move this to another package since the effort involved is really not worth it. Email me if you still have a problem. Regards Lim Swee Tat
Yuck, this makes it even worse. It's a webapp and slotted to ${PVR} meaning the user has to run the config every time a new version is installed. And the files are not recorded in the package database resulting in stale files being left around after unmerging. Just create yourself a small script that downloads the files and tars them up into a datestamped tarball. The tarball is uploaded to our mirrors and you can put it into SRC_URI for downloading.
I'll prefer to not use that approach since I prefer that users get the latest, bestest mods. It's a reasonable approach though. Actually, if you look at the situation now, the ideal is that even with 4.6.3 installed, there are updates to the modules, and themes that warrant just running an update of the modules and themes only.
If you download files directly (actually, you should never do this) you shouldn't mark the ebuilds stable, as you'll never know in what shape the mods will be in the future.
Split the additional modules off into seperate packages (snapshotting the release on our mirrors) if you're after not forcing a full update to the framework for each module release. Meanwhile, wget'ing within config is a no go; great way to orphan files.
st_lim: can we please get this fixed? Also, your description in the ebuild is incredibly long. Make it short and sweet and put the long description in metadata.xml.
What's the current state of this bug?
*** Bug 96908 has been marked as a duplicate of this bug. ***
Since noone seems interested in fixing this, it's been package.masked and will be removed soon unless someone steps up to resolve the outstanding issues.
hi, I'm stepping up :) What about not downloading mods, just draft up a script that does the wget magic to get the latest mods and tell the user at postinst that he needs to use that script to get mods so that he can actually use its drupal install. And obviously there should be a warning about the mods not being supported by gentoo if they fail since they are not properly packaged in a way that eases bugtracking for us.
(In reply to comment #12) > hi, I'm stepping up :) > > What about not downloading mods, just draft up a script that does the wget > magic to get the latest mods and tell the user at postinst that he needs to use > that script to get mods so that he can actually use its drupal install. And > obviously there should be a warning about the mods not being supported by > gentoo if they fail since they are not properly packaged in a way that eases > bugtracking for us. > eselect drupal module maybe? :)
> > What about not downloading mods, just draft up a script that does the wget > > magic to get the latest mods and tell the user at postinst that he needs to use > > that script to get mods so that he can actually use its drupal install. And > > obviously there should be a warning about the mods not being supported by > > gentoo if they fail since they are not properly packaged in a way that eases > > bugtracking for us. > eselect drupal module maybe? :) Only under 2 prerequistes: a) The module doesn't need to download anything. b) The module doesn't need to copy whole directories/bunches of files, but rather symlinks or changes configuration variables. In short: eselect is no package manager and never will be.
As far as I can see, right now the wget part only potentially get's called for drupal 4.6.0: Quote: for item in `cat ${PORTDIR}/www-apps/${PN}/files/${MY_PV}/$i`; do einfo "Unpacking $item" wget -q http://www.drupal.org/files/projects/$item-${MY_PV}.tar.gz /Quote #find /usr/portage/www-apps/drupal/files/ -type d /usr/portage/www-apps/drupal/files/ /usr/portage/www-apps/drupal/files/4.6.0 And in there is not just a "selection of modules", but any drupal module I ever heard of and then some. So why not just drop pkg_postinst() and pkg_config() and be done with it?
Re Comment #11: Yikes. Please don't drop Drupal from Portage. Has anyone bothered to ask upstream to get their act together and make real managed releases of the modules?
(In reply to comment #16) > Re Comment #11: > > Yikes. Please don't drop Drupal from Portage. Has anyone bothered to ask > upstream to get their act together and make real managed releases of the > modules? > Yes and they have, chill. No noe is removing it quite yet.
drupal-4.7.4 doesn't install any 3rd party modules. If users want them they can install them by hand, like all other web apps with plugins.
