#347 sdcc-3.1.0.tar.bz2 will untar with name sdcc

closed
Borut Ražem
None
5
2012-07-11
2012-01-11
rs9562
No

Somewhere during the 2.5.x series of Linux kernels the untar gave you linux-version.
Previous kernels would untar to the name "linux"

I think sdcc should untar to a name with the version, such as sdcc-3.1.0 instead of sdcc.
As far as I recall back to sdcc-2.5.0 the top of tree was always sdcc.

Discussion

  • Borut Ražem
    Borut Ražem
    2012-01-11

    Recategorised to a feature request.

     
  • Borut Ražem
    Borut Ražem
    2012-01-11

    • milestone: 100455 -->
     
    • assigned_to: nobody --> spth
    • status: open --> closed
     
  • Doesn't matter any more, since 3.1.0 is no longer the current release.

    Philipp

     
  • Maarten Brock
    Maarten Brock
    2012-07-10

    Philipp,

    Does the 3.2.0 release untar to sdcc-3.2.0 or still to just sdcc?
    If not, why did you close this one?

    Maarten

     
  • Borut Ražem
    Borut Ražem
    2012-07-10

    It still untar to just sdcc since I forgot about it before making the release build :-(

    I'll update the repack_release.sh script to repack also the src package. Now the repack_release.sh script prepares the release packages without assistance (if everything goes well): downloads the snapshot build, prepares release packages and uploads them to SF file release system. Maarten, you can try to make the test release from one of snapshots, just prevent the upload phase by invoking:

    $ repack_release.sh -dl -pr <snapshot_date> <snapshot_revision> <release_version>

    Be careful: invoking repack_release.sh without options (-dl, -pr, -ul) executes all three phases, so you should kill it before it starts uploading!

    You have to have installed makensis binary: on ubuntu you just install nsis package:

    $ sudo apt-get install nsis

    This will make you prepared as release manager for the next release ;-)

    Borut

     
  • Borut Ražem
    Borut Ražem
    2012-07-10

    • assigned_to: spth --> borutr
    • status: closed --> open
     
  • I'm sorry, I had just assumed the 3.1.0 tarball was a one-off.

    Philipp

     
  • Borut Ražem
    Borut Ražem
    2012-07-11

    From the description it is not evidant which tarballs should be unpacked to sdcc-<version>: src package, binary packages or all of them?

    From the Linux analogy I suppose that only the src package destination has to be renamed. There is also a practical reason against renaming the binary destination IMHO: I suppose that a majority of users have only one (the latest) sdcc version istalled. When they upgrade to the new version, the new version should replace the old one, so there is no need to update the PATH env. variable. This also decrease the possibility to mess up different versions: we already have enough problems to find out which version the user is using...

    If somebody wants to use different sdcc versions in parallel he already knows how to handle it.

    Philipp, Maarten and other developerd, I'd like to hear your opoinion.

    Borut

     
  • Raphael Neider
    Raphael Neider
    2012-07-11

    For sources I agree that unpacking them to sdcc-<version> is better.

    For binaries, I guess this is a matter taste. Unpacking to sdcc-<version>/ allows users to easily test snapshot builds without corrupting known good setups. Just prepend sdcc-<version>/bin to your PATH and you are set up to test the new version. I'd like that.

    On second thought, I would even prefer releases unpacked into sdcc-<version>: Unpacking a new SDCC into an old binary tree calls for trouble if we rename tools/files/directories as the old ones would not be removed.

    For managed installers (windows, debian packages, ...), I would use sdcc/ and make sure to uninstall previously installed versions.

    Best regards
    Raphael

     
  • The source tarballs should definitely have versioned directories. I don't care about binaries.

    Philipp

     
  • Maarten Brock
    Maarten Brock
    2012-07-11

    If I read this request right it asks for source tarballs to unpack to sdcc-<version> and that is also my preference.

    I'm not quite sure how one would use the binary tarball. I don't expect it to be unpacked in /usr/ or something like that so maybe it should also use the version. I think I like that best.

    Maarten

     
  • Borut Ražem
    Borut Ražem
    2012-07-11

    • status: open --> closed
     
  • Borut Ražem
    Borut Ražem
    2012-07-11

    Implemented in repack_release.sh for source and binary packages in svn revision #8037.

    Borut