Directory ownerships again
by Panu Matilainen
I've been playing around with making rpm use runtime-calculated directory
dependencies for additional transaction ordering hints - it gives a nice,
natural and consistent order when directory ownerships are clear. However
things can go very wrong if several unrelated packages own a directory,
for example:
multiprovided dir /usr/share/man/man1
-> filesystem-2.4.21-1.fc11.x86_64
-> gnome-power-manager-2.26.1-3.fc11.x86_64
-> policycoreutils-2.0.62-12.6.fc11.x86_64
Depending on input order, this could end up pulling gnome-power-manager
and a huge pile of gnome dependencies very early into the order where they
really cant be. So the result is a big mess, unless such multiply provided
directories are ignored in the ordering - easy enough to do, just a
lost opportunity to do something useful with existing data.
Using F11 x86_64 DVD as test material, here's the full output with the
owner packages included (lots of duplicates in there):
http://laiskiainen.org/tmp/f11-multiple-dirowners.txt ...and just the
directories which have more than one owner:
http://laiskiainen.org/tmp/f11-multiply-owned-dirs.txt
Translations, language pack packages and such are by far the biggest
single offender group, these have multiple direcotry ownerships all over
the place. The rest are mostly random individual cases of couple of
packages disagreeing with ownership of something or several sub-packages
owning more than they perhaps should.
The "couple of packages disagreeing" cases need to be looked at
case-by-case, but I think for the translations and such a clearer policy
would be good. Having the filesystem package and nothing else own most of
them seems fairly obvious but what should be done when a package
introduces a new translation that filesystem doesn't yet have? Require
filesystem to be updated every time (dunno how often this happens in
reality) or ...?
- Panu -
14 years, 10 months
Digging up an old dead thread ...
by steve
Hi,
First off apologies for the cross-post to fedora-legal-list, this message has
some licensing questions, but I also wanted to keep context without having to
send two separate mails.
First off some background, earlier this year, i expressed a desire to package
some creative commons licensed content ...
https://www.redhat.com/archives/fedora-packaging/2009-February/msg00054.html
After a bit of interest in this topic, including a general consensus that it
might be a good idea, the thread died out since i could not follow up on this
due to lack of time.
Now, however, I do have some time and so I decided to submit a few of packages
as an example of the idea:
https://bugzilla.redhat.com/show_bug.cgi?id=507912
https://bugzilla.redhat.com/show_bug.cgi?id=507915
https://bugzilla.redhat.com/show_bug.cgi?id=507916
(Note that all these submissions are technical books in the same vein as
diveintopython which already exists for Fedora.)
Now, I have 2 questions for fedora-legal:
a. Specific to the last two packages (ldd_pdf and javanotes) -- The upstream
license for both of those specify the license version number (CC-BY-SA version 2
and 2.5), however, the page that lists acceptable licenses for Fedora[1] does
not provide any version numbers. So, should I modify the License tag or should
the wiki page be updated ?
b. About other CC licensed content -- A lot of the available content is licensed
with the Non-Commercial restriction, which is considered as a Bad License
according to the wiki page on licensing. Why is non-commercial only restriction
considered bad ? ...and is there an alternative to including this in the
official Fedora repository -- for instance the rpm fusion repository ?
Now, coming to the original question i raised, would it make sense for me to
submit additional such packages possibly even the non-tech related ? Can we have
an 'alpha', 'beta' or 'rawhide' of a creative commons repository to see if the
idea gains popularity and to create some policies regarding this ?
In any case, for people who'd already are sold on the idea, i've set up a
repository which for now has only 7 rpms (all of them books/tutorials) but I
intend on adding more. I've made them as Fedora Packaging Policy compliant as
possible.
Feel free to try it out and suggest/contribute similar content that you would
like to be packaged.
Note however, that these packages also include the CC content under the
Non-Commercial restriction which Fedora considers Bad.
You may use the repository by creating the file '/etc/yum.repos.d/lonetwin.repo'
with the following lines:
[lonetwin.net]
name=lonetwin's creative commons repo
baseurl=http://lonetwin.net/yum/
enabled=1
gpgcheck=0
..and just in case you are wondering why should you trust my repo ? Well, you
shouldn't. That said, none of the available packages are modified from the
original source, they are just packaged as rpms.
Comments/suggestions are welcome. I hope that this thread does not die out like
the last one.
cheers,
- steve
[1] http://fedoraproject.org/wiki/Licensing#Content_Licenses
14 years, 10 months
OSGi Packaging Changes
by Toshio Kuratomi
Hi Alphonse,
I don't know if anyone from the Packaging Committee emailed you about
changing
https://fedoraproject.org/wiki/Features/OSGiAutoDeps
into a Packaging Draft so I'm making sure you're in the loop :-)
What we need is for the changes to the packaging guidelines to be
written up and presented in draft form. An overview of this process is
here: http://fedoraproject.org/wiki/Packaging/Committee
The draft can be a coy of the new draft based off the existing
guidelines or it can be just the sections that you are adding/modifying.
It should also include any explanation of why the changes are justified
written so someone unfamiliar with the problem space can understand. We
may request more information from you in order to polish the draft.
-Toshio
14 years, 10 months
Renaming of upstream project/rpm/binary
by Federico Hernandez
Hi!
This is not yet happening, but the upstream project wants to do a
rename and release several "binaries" under the new project name. The
current binary and package is one of them:
Now:
project name: foo -->
rpm: foo --> binary: foo
Soon:
project name: FOOBAR -->
rpm FOOBAR --> binary foo
--> binary bar
--> binary ernie
--> binary bert
foo 1.8 --> foobar 2.0
What are the procedures for this? Formal and technical ones? In
particular regarding the "updates". How can I make the old package be
superseeded by the new package.
THX
/Federico
14 years, 10 months
Re: [Fedora-packaging] Help needed on AutoProvReqs subject was (OSGi Packaging Changes)
by Alphonse Van Assche
Hi *,
My first idea was to just update the OSGi section of the Eclipse
plugin packaging guidline but things are more complicated if we will a
complete OSGi deps solving support.
IMO, we need to activate the osgideps.pl script on the whole system
(like the perl one) for the follow reasons:
- Ability to spit package "correctly", I think that the current
eclipse-rcp sub package cannot work without other sub packages[1] at
the same time without the script I don't kow a way to sort that out.
- No need to add defines to each OSGi aware packages.
- Not need to rebuild
[1]
14 years, 10 months
problem with scratch build or mock
by Philippe Makowski
Hi,
I made the src.rpm under F11
then koji build --scratch dist-5E-epel
/home/philippe/rpmbuild/SRPMS/firebird-2.1.3.18156.0-0.fc11.src.rpm
can someone explain me why I get this :
DEBUG util.py:256: error: unpacking of archive failed on file
/builddir/build/SOURCES/Firebird-2.1.3.18156-0.tar.bz2;4a3bf995: cpio:
MD5 sum mismatch
and even using mock -r epel-5-i386 rebuild
./SRPMS/firebird-2.1.3.18156.0-0.fc11.src.rpm
on my box I get into the same trouble
14 years, 10 months
Makefile questions
by Chess Griffin
Hello-
I am familiar with packaging for other *nixes but this is my first RPM
attempt and I have a couple of questions. I have read the various
packaging docs on the Fedora Project site, but have been unable to find
a precise answer. If there is another document to read or another list
where I should be directing these questions, please let me know.
1. The Makefile sets PREFIX to /usr/local. In %install, is it ok
to use:
make install PREFIX=/usr DESTDIR=$RPM_BUILD_ROOT
2. The Makefile also attempts to install and set user/group ownership
and permissions, i.e. it does 'INSTALLBIN= install -g bin -o root -m
555'. Is it ok to address this by patching the line so it reads
'INSTALLBIN= install' seeing as how ownership and permissions are later
set in %files?
3. Similarly, the Makefile also hardcodes the manpage directory, i.e.
in install, it has: '$(INSTALLDIR) $(DESTDIR)$(PREFIX)/man/man1.
Again, is it ok to patch this line so it reads '$(INSTALLDIR)
$(DESTDIR)$PREFIX/share/man/man1'? This package has no ./configure
stage and just uses make and make install, and does not appear to
respect MANDIR.
I have done all these in my draft spec file and the package clears
rpmlint and builds fine with mock, but I wanted to know if what I did
followed convention.
Thanks!
--
Chess Griffin
14 years, 10 months
