maemo.org Bugzilla – Bug 2383
maemo-repository package has misleading description
Last modified: 2008-08-20 07:41:35 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
apt-cache show maemo-repository
Since the sources.list is not actually "provided" by the packages (dpkg -L
maemo-repository doesn't list the file part of the package).
"Description: Configuration for maemo repository.
This package generates the sources.list for maemo repository."
"Description: Configuration for maemo repository.
This package provides the sources.list for maemo repository."
EXTRA SOFTWARE INSTALLED:
trivial fix, wouldn't affect anything other than the description.
Moving to Diablo, and assigning.
Fix would indeed be trivial if found necessary.
I'm assigning this further to Soumya as she's the one currently maintaining
Well, the suggested description is not appropriate either as the package does
not "generate" the sources.list. We will find a most suitable description and
update the package. For eg: This package provides maemo repository entries to
If the package is meant to append to existing sources.list, then that's another
bug :-), because it doesn't do that now:
if [ ! -e /$INSTALL_DIR/sources.list ]; then
echo Copying sources.list..
echo "deb http://repository.maemo.org/ chinook free non-free" >>
echo "deb-src http://repository.maemo.org/ chinook free" >>
(above is the postinst script in it's complete form, other files at
if [ ! -e sources.list ] "seems to imply" that the entries will only be "added"
if the file doesn't exist. I did wonder about the first >> originally, since it
seemed somewhat out of place, but assumed it was just some convention for the
person who wrote the package.
'man test' for explanation of -e.
Suggestion from sp3000 is to actually not touch the sources.list at the root,
but instead add a file under /etc/apt/sources.list.d/ so that the file wouldn't
have to be generated and the configuration could be much more modular.
So having a file like /etc/apt/sources.list.d/maemo-chinook.list that would
contain the two lines.
This would make generating unnecessary and no postinsts would be necessary.
apt on 4.0 sdk does honor that directory if it exists.
Just something to think about if you ever decide to fix this package.
(In reply to comment #4)
> If the package is meant to append to existing sources.list, then that's another
> bug :-), because it doesn't do that now:
Yes. You are right. My mistake in writing the eg. description. The idea behind
the package was not to touch sources.list if it exists.
The package in question is actually not meant to be used outside of scratchbox
or installed separately. It is used as part of the rootstrap generation to
provide the system with the default sources.list. The default for SDK most
certainly is using the SDK repositories and that's why using something under
sources.list.d would be kind of weird.
Also if a package owns the sources.list or something under sources.list.d,
uninstalling it would actually remove the file and that is not desired thus the
use of the postinstall script. Not touching the sources.list when it's already
present is, in my opinion, good practice as the package is not meant to be used
for anything else than the already mentioned rootstrap generation. The package
is provided in the repository only because it is part of the platform and there
is no reason to keep it closed.
The SDK installer provides a way to override the default sources.list if this
is desired, but in most cases it is not.
Could packages "which are useless outside sbox" and "only used as part of
rootstrap generation process" be marked in some way then? This really boils
back to the "not very logical description of the package" which I think is
still the issue.
1) user installs SDK
2) user does dpkg -l to see what's installed
3) "Ooh, maemo-repository, sounds interesting", dpkg -L maemo-repository..
I do disagree with the last comment about not having a sources.list part of the
files _when_ it would be under /etc/apt/sources.list.d/ . The directory is
meant to support this exact use (as well as others).
Editing configuration files on the other hand is error prone and tricky (when
done by packages from within shell scripts).
Also, what will happen if user will remove the package? Nothing. Undoing
changes caused by package installations (intentional or not) by removing
packages should be possible.
While I understand the purpose of the package, and that maemo SDK will not
install just with apt-get but actually requires the rootstrap with all the
hacks in it, I still think this is a valid bug.
If you really really insist that the package operates correctly, why do you
have it as a separate package? Why not have the sources.list directly in the
rootstrap or some script there? Since you have files outside packaging anyway.
Another possibility would be providing a short README with the package. Since
it's only installed in the SDK, disk space usage can't be an issue. This README
could then explain what the package does/is meant for/is not meant for.
Just my .1 cent.
I was told to be more clear on the modularization issue, so this is another try
if maemo-repository package would include the deb/deb-src lines in a file:
Then the following would happen:
1) package installation (during rootstrap generation or whatnot) will add the
maemo repos to apt-get operations.
2) package removal will remove maemo repos lines
3) package listing shows what the package includes
4) dpkg -S /etc/apt/sources.list.d/maemo-repository.list will work and point to
the package that introduced the file
5) No need to change the description of the package! (whee)
Seriously though. Modular configuration has been around in Linux ever since
RedHat ditched inetd for xinetd because of similar issues. Even debian/ubuntu
doesn't use /etc/apt/apt.conf anymore, instead going the modular way
(/etc/apt/apt.conf.d/) as it should've always been.
Other examples include pam, logrotate, cron (/etc/cron.daily anyone?), and
pretty much anything that has survives through the great packaging wars in
Hope this adds some insight.
First of all, maemo-repository is not editing anything. It is creating the
default sources.list when our build system creates the rootstrap, thus it is
not an error prone or tricky. Also contrary to the claims presented here, afaik
all the files in the rootstrap actually do come from packages and we do not
manually add files to the rootstrap. I see no reason to do so in this case
If someone wants to go through packages reading their descriptions and listing
the files they provide they can. If the description is not detailed enough,
that can and will be considered a bug. For the user who wants to know what's
happening with a package that doesn't seem to contain any files, we provide the
sources for that package and it should really tell it all.
Should the removal of sources.list be possible by removing a package? In my
opinion no. I see no reason in removing the default/user provided sources.list.
Also when using user provided sources.list with the installer, I prefer
overwriting files that do not belong to anyone. If you really want to remove
it, you are welcome to do it manually.
As for the modularization issue, even though I do think that sources.list.d is
an excellent feature and we even use it in the scratchbox installer, I don't
feel that it is the right place for the default sources.list at this point and
I haven't seen it used as such in any system I've used.
Even though debian and ubuntu don't use apt.conf but have moved to using
apt.conf.d they both still use sources.list, which btw. isn't owned by any
package but copied in place in the postinstall script. I see no point in making
a move to a totally 'source.listless' setup before the upstream does.
Anyway, this bug is about the package description and it will be acted upon.
For the discussion about who actually provides the sources.list and should it
be owned by some package or put in sources.list.d, you are welcome to open
another bug, but for the reasons stated I doubt it will be modified to meet
your preferences until it's common practice.
Fixed in maemo 4.0.1 release.