Hi,
Sorry if this is a silly question…
Do the distro locations sometimes “go away”?
I have been relying on our friend openSUSE Forums - View Profile: Akoellh who maintains (among others) a very useful distribution of HOSTAPD.
For the last couple of days, this has had no files (although a directory structure exists). Is this normal? Should I just be patient or is something broken?
Regards,
Sorry to read that the application you want is no longer available.
The repository that you mentioned is one of many such repositories put in place by many users. These users typically create such repositories for them selves, or for one time support of someone else, and then for that or other reasons, they simply remove their package.
This sort of repository proliferation is good, in that they can help specific users, but this proliferation is also bad in other users can depend on them, or want the packages present that are no longer packaged.
Such was the case with some chess applications that Akoellh had in his repos, but for his own reasons decided it not worth while to maintain those packages, and he deleted the repository contents.
I raised concerns about the impact such proliferation could have on our openSUSE membership in an openSUSE IRC chat project meeting, where I was concerned our openSUSE membership could be mislead into thinking a USERS custom/home repository promised an ongoing packaging of specific not-available-elsewhere applications, when that was FAR from the intended case. Unfortunately, the meeting’s resolution was to put an action on me to propose something in FATE, and I have not the time to do so. I noted in the IRC chat meeting I did not have the time and was reluctant to accept such an action, and I was offered help in teaching me FATE. But help does not help, if one does not have the time. I do not have the time. Hence in part, I am to blaime.
I also raised this concern with yaloki, but I suspect he is also very busy.
My recommendation is if you get ANY rpm from ANY private users repository, you should copy from the repository the rpm files (including the .src) that you need, so that you can rebuild them later yourself. Else you will be subjected to the vagarities of the emotional (and logical) responses of those users, who do not intend to offer a long time packaging service, but who are rather providing very limited time frame support/testing.
Thank you, “oldcpu”,
Particularly for taking the time to explain the situation. I can now begin to see (and better understand) some of the problems involved.
Finally, I shall take heed of your advice to “grab a copy” in the future. Although, I’m a long way off being able to use the source yet!
Regards, Martin
The reason is simple.
Due to lack of time and motivation, I deleted my “personal” repos.
Only leaving stuff uploaded without actively maintaining it is IMHO half hearted, so I decided to make a clean cut.
Some of the packages might be available in other repos, the packages I started to build stuff in OBS are available in driver:/wireless and will be maintained by me until they will become obsolete (which might be quite soon for some packages).
P.S.
The directory structure was not deleted but this is something beyond my responsibility, the projects themselves were deleted by me if possible.
I could not delete one of the projects, because some other user has linked one of my packages into his repo. Funny enough I found that out after actually having already deleted the respective package, which for me is quite an inconsistent behavior of OBS.
Rebuilding from the “src” rpm is IMHO often easier than having to custom compile from the (./configure, make, make install) and has the added advantage of building an rpm that may have superior dependency checking than if one built an rpm via checkinstall. A lot depends of course on the quality of the rpm built by the “user” who posted the rpm in their private repository.
If you manage to get one of the " src " files for the application that you seek, then post the file name of the rpm here, and one of us may be able to explain to you how to rebuild the rpm for your PC using the rpm rebuild.
Often, if one has applied the “base development” pattern from YaST, and installed any other needed devel packages, its a simple matter of running with root permissions
rpmbuild --rebuild /path/to/the-rpm/application-package-name.src.rpm
The key here, is to GRAB the src files BEFORE that user deletes them. I am now in the habit of always grabbing such .src files.
That won’t help anyone else if the repos has been removed, but it will help you. 
If these “root permissions” are also related to the rebuild procedure (for installing dependencies root is of course needed), then I have to object strongly.
Never (re)build rpm packages with root permissions.
There is even an important tag in a “good” spec called:
# norootforbuild
I’m no expert on this so I can only ask questions here, and not dispute any strong objection …
I typically try to rebuild first as a regular user. … but more often than not it will fail. But a rebuild with root permissions will not fail. Why? Was the src file built incorrectly? Or possibly because my experience and my efforts to rebuild rpms are typically only for drivers such as webcam, wireless … where for those root permissions may be needed ?
If during the rebuild, the src indicates to write to /usr/bin or other directories that require root permissions, will it not fail if run as a regular user ? Or does it stop and prompt for root password at that point? I typically get failures (crippling failures) at that point.
Likely better guidance is needed, in terms of what applications need root and which do not? Can one rebuild a wireless rpm without root permissions?
Then the packager did something wrong, normally a RPM should be buildable as a normal user.
No build process -no matter if via rpmbuild or classic ./configure && make- should require root privileges, only installing should.
Using rpmbuild as root is even more dangerous than a simple “make”, because there actually is an “installation” step involved, which normally should go into $RPM_BUILD_ROOT.
And there are those funny, little steps where a typo or even malicious “error” can damage the whole system when running rpmbuild as root.
%clean
rm -rf %{buildroot}
Now what would happen if the packager sets %{buildroot} to ‘/’?
P.S.
One of the final tests before I published any package was to run rpmbuild --rebuild on the src.rpms and see if that works.
That makes perfect sense. I need to recheck my notes, as my memory is failing me, I am not at a Linux PC right now, and I am struggling with a bad headache to boot.
So martinprowe, reference my above, as a REGULAR user, run
rpmbuild --rebuild /path/to/the-rpm/application-package-name.src.rpm
Opps… I didn’t mean to start anything!
It was only my naivety that sparked the question. However, If Akoellh is still listening, could I ask if you would mind mailing me the hostapd 0.9.something package?
You may remember from a few months back on this forum, we had a fairly lengthy conversation about this build and its advantages over the 0.4 build in the “official” SuSE repos?
Armed with a specific task, I hope, I can take advantage of the advice provided higher up this thread.
Regards, Martin
Not if done correctly by the packager.
That’s exactly what I wrote above about “install into $RPM_BUILD_ROOT” (or % {buildroot} which is synonym), which typically is /var/tmp/Name_of_package-Version-build/ (or similar) and is explicitly created by rpmbuild for that purpose.
Typical procedures are:
%install
make DESTDIR=$RPM_BUILD_ROOT install
which will install the whole strutcure like a “make install” (with /usr /lib/ /etc, /whatever) to the RPM_BUILD_ROOT-directory instead of /.
%install
%__install -D -m0755 ./src/multiget "%{buildroot}%{_bindir}/multiget"
%__install -D -m0644 "%{SOURCE1}" "%{buildroot}%{_datadir}/applications/multiget.desktop"
%__install -D -m0644 "%{SOURCE2}" "%{buildroot}%{_datadir}/man/man1/multiget.1.gz"
%__install -D -m0644 newicons/48/logo_48.xpm "%{buildroot}%{_datadir}/pixmaps/multiget.xpm"
You didn’t start anything bad, on the contrary, for me it was important to have the possibility in trying to make clear why in > 99% of all cases it’s the packager’s fault if a build as user fails.
I am sorry, but the answer is no.
First of all there are no more ready made binary packages, secondly I would only send specs and patches to people who would like to start maintaining the respective package in their own repo and thirdly, if I would start doing this now, I would have to do this for everybody asking similar questions than you did.
For a “normal user” (= somebody who does not want to maintain packages) searching in OBS for alternatives will be the better solution.
If there are no alternatives (for hostapd i am pretty sure there are), then bad luck.