sce-import numbering problems

[jls]

Hi

Code: [Select]

The SCE(s) below will provide dependencies for emodule-alarm.sce.

e21-plain

Merging 10 packages (163 - 153 dependency provided):

1/10 emodule-alarm-data
Connecting to repository.elivecd.org (188.226.235.52:80)
libedbus-bin_2.6.18+ 100% |*******************************| 29814   0:00:00 ETA
2/10 libedbus-bin
Connecting to repository.elivecd.org (188.226.235.52:80)
libedbus1_2.6.18+1.7 100% |*******************************|   105k  0:00:00 ETA
9/10 libedbus1
10/10 emodule-alarm
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on /etc/sysconfig/tcedir/sce/emodule-alarm.sce, block si
ze 4096.


Thanks

[Jason W]

Ok, imported e21-plain, used it as an SCE dep for emodule-alarm, and I see the same.

What has happened is that there is package listings in that enlightenment repo that don't exist, so they don't get merged.  Our ability to use list files and create meta packages depends on package names being allowed to not exist, so to prevent them from not being listed would break a lot of the import features we know of.  Until the numbering issue we see here we just never saw those the issue. 

But I will take another look and see what we may can do to at least let folks know when a package name does not exist in a repo.

[Jason W]

In latest RC now showing packages during import that are either meta or non existent. 

We can ponder whether we want to exit sce-import in the case of a non existent package.

[Jason W]

I uploaded a minor adjustment that tells whether a package is a dCore meta package or a Debian/Ubuntu one if the package name is not found in any repo.  Due to the nature of virtual packages in the Debian repos, it is not possible to tell whether a package is misnamed, does not exist, or is simply a virtual one.  So we have to settle on this info being provided during import.