search

veso266 / impacket

Automatically exported from code.google.com/p/impacket
Other
0 stars 0 forks source link

bad packaging #21

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
In the file: http://impacket.googlecode.com/files/impacket-0.9.9.9.tar.gz

- Impacket.spec
  - notice how the spec's name doesn't reflect the package name?
    - the case of the leading 'i'/'I' is different
  - %define version 0.9.9.0_dev
    - is not the same version as the "published" package's version (0.9.9.9)
  - %define unmangled_version 0.9.9.0-dev
    - ditto
    - additionally, since the spec is directing rpmbuild to use "{tgz_name}-%{unmangled_version}.tar.gz" (in the Source0 tag) to find the source tarball, it fails since the source is named impacket-0.9.9.9.tar.gz per the "published" version
  - License: UNKNOWN
    - should reflect the actual license of the software
  - %description
    - should provide at least a brief description of the package

All of these errors make it difficult to programmatically build your package 
with the same code that can successfully build any other properly published 
python package such as those found on http://pypi.python.org/.

The unmangled_version fubar makes it actually impossible to build the package 
at all without having to manually correct the Impact.spec file.

Original issue reported on code.google.com by brianjmu...@gmail.com on 3 Jan 2013 at 10:06

GoogleCodeExporter commented 9 years ago 
Hrm.  Looking at the setup.py for the 0.9.9.9 release it seems that you failed 
to update the setup(version) prior to doing the builds.  This seems to be a 
chronic issue as it appears to be the case on svn/tags/impacket_0_9_8_0/ and 
svn/tags/impacket_0_9_7_0/ also.  You really need to make these things all 
match up.

You cannot simply rename the resulting .tar.gz and expect everything to be good.

Original comment by brianjmu...@gmail.com on 3 Jan 2013 at 10:41

GoogleCodeExporter commented 9 years ago 
Hey Brian:

Thanks for the report and sorry for the messed up package. We'll be fixing it 
these days.

Stay tunned.

Original comment by bet...@gmail.com on 6 Jan 2013 at 6:11

GoogleCodeExporter commented 9 years ago

Original comment by bet...@gmail.com on 10 Jan 2013 at 4:34

GoogleCodeExporter commented 9 years ago 
Hi.

To be clear, you need to adjust the version in setup.py to reflect what you 
want the resulting release to ship as, before you do the release process so 
that things are all named/versioned correctly.  I would suggest that that 
version given should match the release branch/tag name.

Original comment by brianjmu...@gmail.com on 10 Jan 2013 at 4:53

GoogleCodeExporter commented 9 years ago 
I've modified some of the properties of the setup.py file. This new version is 
attached, does this modifications fix the issues you have to create the package.

Original comment by 6e7...@gmail.com on 10 Jan 2013 at 7:17

Attachments:

GoogleCodeExporter commented 9 years ago 
Well, that setup.py is fine if what you want as a result is 
impacket-0.9.9.9.tar.gz.  But you have already released 0.9.9.9 at:

http://corelabs.coresecurity.com/index.php?module=Wiki&action=attachment&type=to
ol&page=Impacket&file=impacket-0.9.9.9.tar.gz

Surely you don't actually want to re-release 0.9.9.9 right?  If you don't, then 
you need to decide what the version of the next release will be and set the 
version property to that value.

Currently on trunk the version is 1.0.0.0-dev.  That seems like a reasonable 
version while trunk is in development given that the previous release was 
0.9.9.9.  But at the point where you are ready to do an official release, you 
would want to set that version to "1.0.0.0" so that the tarball you get is 
impacket-1.0.0.0.tar.gz (the zip file will be similar).  It's that tarball (and 
zip file) that you make available as your release to your users, _WITHOUT_ 
doing anything to them to change the version in their name.  That's the 
important part.  Once "setup bdist" (or whatever variant you use) has created 
and named the tarball and/or zip files, you cannot change the version (nor 
should you really change the name) in the file name.

Original comment by brianjmu...@gmail.com on 22 Jan 2013 at 8:13

GoogleCodeExporter commented 9 years ago 
Additionally at the point in the source tree where you did the "setup bdist" to 
make your 1.0.0.0 release (with the setup.py version="1.0.0.0" you would create 
a tag "impacket_1_0_0_0" so that you have perfect alignment of setup.py 
version= value, the names on the released packages and the SCCS tag.

Original comment by brianjmu...@gmail.com on 22 Jan 2013 at 8:15

GoogleCodeExporter commented 9 years ago 
Hey Brian..

Thanks for all your points.. we will not be changing 0.9.9.9 since, as you 
said, it's already out there. 

We will incorporate these changes whenever we release the next version.

thanks again,
beto

Original comment by bet...@gmail.com on 25 Jan 2013 at 8:14

GoogleCodeExporter commented 9 years ago 
We just published 0.9.10.. Hopefully those problems are solved.

Original comment by bet...@gmail.com on 6 May 2013 at 5:47