Spec File Frustration (rant)

Home » CentOS » Spec File Frustration (rant)
CentOS 21 Comments

I’m getting spec files from CentOS git which is really convenient when the related source is easy to find. But some things – e.g. from a spec file

# How to create the source tarball:
#
# git clone git://git.fedorahosted.org/git/python-rhsm.git/
# cd client/python-rhsm
# tito build –tag python-rhsm-$VERSION-$RELEASE –tgz

Never used tito before, so I install it and try, and rather than giving me the source package I need – it gives me a python traceback complaining that I haven’t configured some things properly.

Seems a lot of the software distribution world is getting overly complex with an expectation that the end user who needs to exercise his FLOSS
rights has to use git or nodejs or for php composer or whatever just to get what use to be available with no more complexity than choosing tar.gz or tar.bz2 or .zip if the dev was Windows.

Whatever happened to KISS and why can’t source tarballs be distributed as source tarballs?

Back when I was a Fedora packager – the packaging guidelines would reject a package of the Source tarball wasn’t a URL and if the timestamp on the tarball in the src.rpm didn’t match upstream even if the checksum was identical.

Guess those days are gone.

/rant

21 thoughts on - Spec File Frustration (rant)


  • Not exactly. I’m pretty happy with FreeBSD pkg system, and with poudriere whenever I need custom configs different from what package maintainers choice. No unneeded complication crap.

    Of course, this is only rant from point of view of mentioning our rival:
    FreeBSD on our list ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • that doesn’t solve the issue of various FOSS projects using all kinda whacky build toolkits and requirements.

    one tool I wanted to build a few weeks ago depended on common lisp.

    another package I wanted to play with required this whole complex python infrastructure which I’d never seen or heard of before (Im not a python dev although I can follow bits of code, and even make minor changes), and the build commands in that infrastructure were pulling in source packages from various servers all over the world, which kinda scared me from a security standpoint.

  • That is inevitable: some of the tools/projects to work may require you to bring a huge external infrastructure if you want to use them. This has no way around.

    Another thing is: when building of the project (libraries, binaries, etc)
    requires sophisticated infrastructure that is not necessary after you built it. This and only this is what I meant when mentioned FreeBSD pkg and poudriere for building custom configured packages – you only need that infrastructure when building (on build box in build jail…).

    But in general, yes, the world seems to have gone the way “why simple, when you can do it complex way”.

    I guess I should have added rant tags…

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Yes, that’s why I mentioned nodejs. A rather cool JavaScript project didn’t do quite what I wanted, but to modify it I had to install some nodejs environment that was used to “build” the JavaScript and had to be re-run for any tweak to the components and always built a rather large JavaScript file even minified.

    I ended up just scrapping it any writing my own even though its not as flexible, and I’m still trying to figure out how requiring a node setup is a good idea to require for generating a static file.

    But that’s the trend.

  • I went to the github and it doesn’t have a packaged release that matches the version. I managed to find it in the build system logs, but its just weird.

    If I recall, formerly for a tarball to be different than what was on upstream, it had to have a legal reason (e.g. patents) and a script in the sources that could turn upstream tarball into the version used.

  • Hi,

    To get source for a package in CentOS, you follow the get_sources.sh’
    section and ‘Example workflow’ section in:

    https://wiki.CentOS.org/Sources

    For your package…

    * Setup ‘CentOS-git-common’ i.e. clone it to your system.

    * Do the clone and checkout for your package.

    git clone https://git.CentOS.org/summary/rpms!python-rhsm.git cd python-rhsm git checkout c7
    sh /get_sources.sh

    You should then have the spec, any patches and tarball(s).

    Regards

    Phil

  • Hello Alice,

    Seems like a valid issue to take upstream. Especially since Red Hat now uses the CentOS repo to provide their sources to the public.

    It is possible to get a free RH developer account (speaking of transparency, it took me a while to find the right banner to click on to actually get that free account ;p ), but the source code is only provided as 2 dvds and it is unclear to me where to find sources for updated packages. Or perhaps you have to download 2 dvds every time they update that image. Ouch.

    Regards, Leonard.

  • Hello Valeri,

    The point is not that one requires (many) tools to build a project, the problem is that tools like f.e. composer make it unclear to the user what exactly is being pulled from where and for what reason and whether the pulled sources are being verified with checksums. Just providing a text with a set of requirements and urls makes it much easier for the user to verify the sources. It’s about transparency.

    Regards, Leonard.

  • I am not sure what you are trying to accomplish .. but the tools to get an SRPM or the Sources from CentOS are dead simple.

    They are located here:

    https://git.CentOS.org/summary/CentOS-git-common.git

    And they are very easy .. and most are bash scripts.

    So:

    git clone https://git.CentOS.org/summary/rpms!skopeo

    (that just happens to be what I am working on right now)

    cd skopeo

    git branch -a (so you can see the branches .. optional)

    git checkout c7-extras

    get_sources.sh

    =================

    Now you have the full SRPM in the same directory structure as if you had installed the SRPM.

    If you would have used ‘into_srpm.sh’ instead of ‘get_sources.sh’ .. you would have the SRPM generated as well as the full tree. There are switches for the tools (-c for get_sources.sh to check the crc info for already downloaded files .. -d for into_srpm.sh for changing the dist tag of a generated SRPM, etc.)

    I use these tools for every package built for CentOS and they are very easy to use.

    Now, obviously that does not include development inside an extracted SRPM. But I normally just use diff (or git) to track changes and generate patches, etc.

    Thanks, Johnny Hughes

  • Hello Johnny,

    Apart from the syntax error because the exclamation mark is not escaped this leads nowhere.

    So I tried:

    $ git clone https://git.CentOS.org/git/rpms/skopeo.git

    So far so good. We now got a spec file. Doing the same for bc: a spec file and patches. Still no source.

    The name suggests this is what we need (or do we??) If only I could find that script anywhere…

    So lets dig around a bit:

    skopeo]$ cat .gitignore SOURCES/skopeo-1f655f3.tar.gz

    bc]$ cat .gitignore SOURCES/bc-1.06.95.tar.bz2

    python-rhsm]$ cat .gitignore SOURCES/python-rhsm-1.17.9.tar.gz

    I think this solves Alice’s issue once the .gitignore file is fixed.

    For some reason the tarballs seem to be ignored. Something I need to fix in my git config or is it at your end?

    Regards, Leonard.

  • Hello Jonathan,

    Thanks for pointing out my oversight.

    However, cloning that repo does not work…

    $ git clone https://git.CentOS.org/summary/CentOS-git-common.git Initialized empty Git repository in /data/leonard/srcothers/CentOS/CentOS-git-common/.git/
    warning: remote HEAD refers to nonexistent ref, unable to checkout.

    What am I missing?

    And then there remains the question: git checkout for a package gathers the spec file and patches, so why do we need a script to get the source tarball when all that is stopping it from getting checked out is an entry in .gitignore? A whole script to undo that one entry in .gitignore? What’s the idea behind this?

    Regards, Leonard.

  • Hello Phil,

    Too late to boost my brain with more coffee for today. Not as sharp as I
    would like to be ;) .

    Still leaves me with the question why a script to download the source tarballs is needed when just not adding a .gitignore entry for them to the repos would fix the issue. Could someone involved care to explain the rationale behind this or point me to a thread where this has been discussed/explained?

    Cheers, Leonard.

  • Not sure what you are asking.

    You don’t want to put large GZ tarballs in git .. we only put text file in git. All binary files are put in a look-aside cache.

    So, when you do git clone you get all the text sources .. when you do get_sources.sh (or into_srpm.sh) you get all the binary sources
    (tarballs, etc.). You need both to be able to build the SRPM.