packaging of updated modules

2007-02-27
2013-05-20
  • Brett Shadbolt
    Brett Shadbolt
    2007-02-27

    Hi,

    It would be very helpful if all updated modules used the correct directory structure. I'm not sure exactly how to put this in technical terms but here is an example:

    The latest core update is in an archive labelled "base_1_4_1.tar.gz" or similar. When this is extracted it goes into a directory called "base_1_4_1".

    I am running phpwebsite on a shared host and the only way I have of extacting these files is by using the graphical interface provided by the service provider. I cannot move the new directory - base_1_4_1 - into the document root for my site, it just isn't possible.

    This seems to be the case for about half of the modules that I have to update, some are extracted into obscure directories that I cannot use, while some can be extracted directly into either the 'mod' directory or docroot directory.

    The only way I can get around this is by extracting the updated archives on my own computer first, manually changing the directory structure, re-archiving the files and then uploading and extracting on the server. I am sure a number of people on hosted environments have the same problems.

    It would be better to create the archives with the standard directory structure - i.e. all modules can be extracted from within the 'mod' directory, a core update can be extracted from within the docroot directory, etc

    Cheers,

    Brett

     
    • I am having difficulties with this issue.

      Originally, I had all modules untar into a their respective module directory. For example, if I shipped blog_1_0_0.tgz and it was untarred, you would get:

      blog/

      So if you untarred that in the mod directory, you were all done.

      This confused people. So I changed it so that you could untar it in the root of the installation.

      mod/blog/

      The problem with this was it didn't give people ample warning. They would overwrite their past content before having a chance to backup.

      Sooooo now all updated modules follow this form (using blog as an example)

      blog_1_0_0/mod/blog

      Meanwhile, I used to ship core updates so they would untar as

      core_1_0_0/

      The contents of which you would copy into your root installation. The problem with this was some people thought "core" meant it should be untarred into the "core" directory. The core directory contains just the core classes while the update updates those plus javascript, the index file, etc.

      So I changed it to "base" to give people pause while they figured out its function.

      In the end, all updates should work as follows:
      tar zxf name_of_tarball.tgz
      cp -fr name_of_tarball/* phpwebsite/

      If you made it this far, congratulations ;-) My point is, I'm not sure what is the most consistent method of update. I need to cement a concise method however because the more I change, the more confusion it causes.

      I will link this page in the developer mailing list and see what others say. Thank you for your post.

      Matt

       
      • I personally don't have a problem with the way you are doing it now, though I can see where it might confuse some others.

        For myself though, I like blog_1_0_0.tgz expanding to
        blog_1_0_0/mod/blog

        It shows me what I have (which is nice when I like to archive various versions) and where the parts go. The same in the case of base files. Perhaps a generic README file in all packages explaining that the contents reflect the location for the files relative to your site's root, would help.

        If I understand what brettshadbolt is describing, although I can feel his pain, I sure wouldn't want base_1_0_0 just expanding to wherever it happened to be. I can just picture the mess the first time I happened to do this on my desktop for a peekaboo. I'd be pissed at all those files on my desktop and not in a folder of some sort!

        My 2 cents,